Hey all,
I made the first commit on LP after our trunk branch was established and it went smoothly. So, everyone, feel free to go to town!
As a side thought, since 0.48 will be maintained for a bit while 0.49 is under development. What do people think about our use of LP and how we use Fix Released rather than Fix Committed... are people game to perhaps try using Fix Committed (and target them for 0.48 when doing so) for this cycle? If we properly use committed and mark where it will be available, we can then just script it to change to released when it really is (I think it will be nicer for users). Just a thought.
Cheers, Josh
As a side thought, since 0.48 will be maintained for a bit while 0.49 is under development. What do people think about our use of LP and how we use Fix Released rather than Fix Committed... are people game to perhaps try using Fix Committed (and target them for 0.48 when doing so) for this cycle?
Launchpad will automatically mark a bug "Fix Available" (rather than "Fix Committed") once somebody commits using the flag --fixes, e.g. bzr commit --fixes lp:123456 --fixes lp:123457 (if you fix those two bugs in one commit). Then, bugs can be changed automatically from "Fix Available" to "Fix Released"
Regards, Krzysztof
On Sun, 2009-11-29 at 01:25 +0100, Krzysztof Kosiński wrote:
As a side thought, since 0.48 will be maintained for a bit while 0.49 is under development. What do people think about our use of LP and how we use Fix Released rather than Fix Committed... are people game to perhaps try using Fix Committed (and target them for 0.48 when doing so) for this cycle?
Launchpad will automatically mark a bug "Fix Available" (rather than "Fix Committed") once somebody commits using the flag --fixes, e.g. bzr commit --fixes lp:123456 --fixes lp:123457 (if you fix those two bugs in one commit). Then, bugs can be changed automatically from "Fix Available" to "Fix Released"
Aha! Thanks for that info!
Cheers, Josh
On Sat, 2009-11-28 at 16:05 -0800, Joshua A. Andler wrote:
I made the first commit on LP after our trunk branch was established and it went smoothly. So, everyone, feel free to go to town!
Yeah! I'll see if I can clean up the GSoC branches a little once I have upload bandwidth again. I think merging trunk into them would make things much simpler.
As a side thought, since 0.48 will be maintained for a bit while 0.49 is under development. What do people think about our use of LP and how we use Fix Released rather than Fix Committed... are people game to perhaps try using Fix Committed (and target them for 0.48 when doing so) for this cycle? If we properly use committed and mark where it will be available, we can then just script it to change to released when it really is (I think it will be nicer for users). Just a thought.
I like "Fix Committed" meaning that it landed on trunk. And "Fix Released" meaning that it's in a tarball. I keep pushing for the script you're talking about there being a button in LP... hopefully it will be soon-ish. Until then, I'm pretty sure such a script already exists.
--Ted
De : Krzysztof Kosiński <tweenk.pl@...400...> Launchpad will automatically mark a bug "Fix Available" (rather than "Fix Committed") once somebody commits using the flag --fixes, e.g. bzr commit --fixes lp:123456 --fixes lp:123457 (if you fix those two bugs in one commit). Then, bugs can be changed automatically from "Fix Available" to "Fix Released"
Thanks for the tip. I've tried it with Bug 485027 (Export to Gimp XCF returns deprecation warnings: https://bugs.edge.launchpad.net/inkscape/+bug/485027), and the report is now linked to the branch. But "Fix Available" is not a visible LP status, and you still need to change the report to "Fix committed" manually. According to Using Bazaar With Launchpad (http://doc.bazaar-vcs.org/bzr.dev/en/tutorials/using_bazaar_with_launchpad.h...), automatic status changes is currently under development.
Regards, -- Nicolas
Probably a stupid question, but can I do updates and commits without creating a "branch"?
I'm not against branches in principle, but with SVN I was doing compulsive updates many times a day. Now, whenever everything changes, I must commit someone's updates into my branch, and think up a commit message for that, even if I have no idea what those changes were. That's a bit much for me, frankly.
Also, if I do a commit of merge changes into my branch, then do some changes of my own, and then push it all to the trunk - will my merge commits be pushed as well? If not why?
On Mon, 2009-11-30 at 23:19 -0400, bulia byak wrote:
Probably a stupid question, but can I do updates and commits without creating a "branch"?
Yes. A branch is a generic term here, not necessarily meaning a divergence from trunk.
I'm not against branches in principle, but with SVN I was doing compulsive updates many times a day. Now, whenever everything changes, I must commit someone's updates into my branch, and think up a commit message for that, even if I have no idea what those changes were. That's a bit much for me, frankly.
Probably want you want is to bind your branch to trunk. What that means is that you'll commit to trunk and then update, it makes things work very much like SVN. You always have to be connected, and you can't commit if someone else has changed trunk.
$ bzr branch lp:inkscape $ cd inkscape $ bzr bind lp:inkscape <do work> $ bzr commit <error, someone else has changed things> $ bzr update <check all is okay> $ bzr commit
Also, if I do a commit of merge changes into my branch, then do some changes of my own, and then push it all to the trunk - will my merge commits be pushed as well? If not why?
Yes.
--Ted
The way I do it is 'bzr branch lp:inkscape' to make my local copy and then I work out of that copy.
Do 'bzr pull' when you want to update (like svn up).
Then 'bzr commit -m "message"' to commit locally, and finally 'bzr push' when you want to push it to trunk.
Cheers, Josh
On Nov 30, 2009 7:19 PM, "bulia byak" <buliabyak@...400...> wrote:
Probably a stupid question, but can I do updates and commits without creating a "branch"?
I'm not against branches in principle, but with SVN I was doing compulsive updates many times a day. Now, whenever everything changes, I must commit someone's updates into my branch, and think up a commit message for that, even if I have no idea what those changes were. That's a bit much for me, frankly.
Also, if I do a commit of merge changes into my branch, then do some changes of my own, and then push it all to the trunk - will my merge commits be pushed as well? If not why?
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
2009/11/30 Ted Gould <ted@...11...>:
Probably want you want is to bind your branch to trunk. What that means is that you'll commit to trunk and then update, it makes things work very much like SVN. You always have to be connected, and you can't commit if someone else has changed trunk.
This sounds like what I need, but:
$ bzr branch lp:inkscape $ cd inkscape $ bzr bind lp:inkscape <do work> $ bzr commit
I get this:
$ bzr commit -m "..." Format <RepositoryFormatKnit4> for file:///home/d/ink/inkscape-bzr/inkscape/.bzr/ is deprecated - please use 'bzr upgrade' to get better performance bzr: ERROR: Cannot lock LockDir(http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/.bzr/repository/loc...): Transport operation not possible: http does not support mkdir()
2009/12/1 bulia byak <buliabyak@...400...>:
Probably a stupid question, but can I do updates and commits without creating a "branch"?
I'm not against branches in principle, but with SVN I was doing compulsive updates many times a day. Now, whenever everything changes, I must commit someone's updates into my branch, and think up a commit message for that, even if I have no idea what those changes were. That's a bit much for me, frankly.
I ran into the same problem when doing my first experiments with bzr and was a bit confused that a simple analogue to "svn update" shouldn't be possible with bzr. I cannot remember which instructions I followed when doing my first checkout (there were a few on the wiki and on the mailing list), but it took me a bit to find what Josh suggested: bzr pull / bzr commit -m "message" / bzr push. I haven't had the time to further play around with it (and won't for another week or so), but it seems to me that this should be the recommended way for first-time users of bzr switching from SVN (since it behaves more or less the way one is used to from SVN but retains the advantages of a DVCS and doesn't introduce the limitations which result from binding one's branch to trunk). Could someone with more knowledge of bazaar confirm this and maybe add this to an appropriate section of the "Working with bazaar" page on the wiki? Also, it would be good to add an explanation of how to push (or 'commit' in SVN lingo) to the "SVN-style checkout" section on that page.
Thanks! Max
On Tue, 2009-12-01 at 01:18 -0400, bulia byak wrote:
2009/11/30 Ted Gould <ted@...11...>:
Probably want you want is to bind your branch to trunk. What that means is that you'll commit to trunk and then update, it makes things work very much like SVN. You always have to be connected, and you can't commit if someone else has changed trunk.
This sounds like what I need, but:
$ bzr branch lp:inkscape $ cd inkscape $ bzr bind lp:inkscape
<do work> $ bzr commit
I get this:
$ bzr commit -m "..." Format <RepositoryFormatKnit4> for file:///home/d/ink/inkscape-bzr/inkscape/.bzr/ is deprecated - please use 'bzr upgrade' to get better performance bzr: ERROR: Cannot lock LockDir(http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/.bzr/repository/loc...): Transport operation not possible: http does not support mkdir()
This is because you haven't told bazaar your launchpad ID so you don't have permission to upload :)
You probably want to run two commands actually:
$ bzr whoami
Which sets your name and e-mail address, otherwise it defaults to username@...2282... which isn't that useful. Then you should also set your LP ID with:
$ bzr launchpad-login
Sorry, should have included these earlier -- I just set them long ago :)
--Ted
On Tue, 2009-12-01 at 08:46 -0600, Ted Gould wrote:
On Tue, 2009-12-01 at 01:18 -0400, bulia byak wrote:
2009/11/30 Ted Gould <ted@...11...>:
Probably want you want is to bind your branch to trunk. What that means is that you'll commit to trunk and then update, it makes things work very much like SVN. You always have to be connected, and you can't commit if someone else has changed trunk.
This sounds like what I need, but:
$ bzr branch lp:inkscape $ cd inkscape $ bzr bind lp:inkscape
<do work> $ bzr commit
I get this:
$ bzr commit -m "..." Format <RepositoryFormatKnit4> for file:///home/d/ink/inkscape-bzr/inkscape/.bzr/ is deprecated - please use 'bzr upgrade' to get better performance bzr: ERROR: Cannot lock LockDir(http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/.bzr/repository/loc...): Transport operation not possible: http does not support mkdir()
This is because you haven't told bazaar your launchpad ID so you don't have permission to upload :)
You probably want to run two commands actually:
$ bzr whoami
Which sets your name and e-mail address, otherwise it defaults to username@...2282... which isn't that useful. Then you should also set your LP ID with:
$ bzr launchpad-login
Sorry, should have included these earlier -- I just set them long ago :)
I got that far with bulia via chatting last night... he got his ssh key uploaded, logged in via command line, bzr whoami says what it should, bzr missing shows that it's liked to the server repo and it's up-to-date, but it's still throwing the same error on him when he tries to commit.
Cheers, Josh
On Tue, 2009-12-01 at 09:33 -0800, Joshua A. Andler wrote:
On Tue, 2009-12-01 at 08:46 -0600, Ted Gould wrote:
On Tue, 2009-12-01 at 01:18 -0400, bulia byak wrote:
2009/11/30 Ted Gould <ted@...11...>:
Probably want you want is to bind your branch to trunk. What that means is that you'll commit to trunk and then update, it makes things work very much like SVN. You always have to be connected, and you can't commit if someone else has changed trunk.
This sounds like what I need, but:
$ bzr branch lp:inkscape $ cd inkscape $ bzr bind lp:inkscape
<do work> $ bzr commit
I get this:
$ bzr commit -m "..." Format <RepositoryFormatKnit4> for file:///home/d/ink/inkscape-bzr/inkscape/.bzr/ is deprecated - please use 'bzr upgrade' to get better performance bzr: ERROR: Cannot lock LockDir(http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/.bzr/repository/loc...): Transport operation not possible: http does not support mkdir()
This is because you haven't told bazaar your launchpad ID so you don't have permission to upload :)
You probably want to run two commands actually:
$ bzr whoami
Which sets your name and e-mail address, otherwise it defaults to username@...2282... which isn't that useful. Then you should also set your LP ID with:
$ bzr launchpad-login
Sorry, should have included these earlier -- I just set them long ago :)
I got that far with bulia via chatting last night... he got his ssh key uploaded, logged in via command line, bzr whoami says what it should, bzr missing shows that it's liked to the server repo and it's up-to-date, but it's still throwing the same error on him when he tries to commit.
My guess would be that when he did the "bzr bind" it resolved to use the 'http' address (non-login) so if he did "bzr unbind" and then "bzr bind lp:inkscape" again it would change the ssh+bzr: URL.
--Ted
On Tue, Dec 1, 2009 at 1:39 PM, Ted Gould <ted@...11...> wrote:
My guess would be that when he did the "bzr bind" it resolved to use the 'http' address (non-login) so if he did "bzr unbind" and then "bzr bind lp:inkscape" again it would change the ssh+bzr: URL.
Yes, that worked. Thanks everyone!
Will it ask for the passphrase every time I commit, as it just did?
On Tue, Dec 1, 2009 at 1:50 PM, bulia byak <buliabyak@...400...> wrote:
On Tue, Dec 1, 2009 at 1:39 PM, Ted Gould <ted@...11...> wrote:
My guess would be that when he did the "bzr bind" it resolved to use the 'http' address (non-login) so if he did "bzr unbind" and then "bzr bind lp:inkscape" again it would change the ssh+bzr: URL.
Yes, that worked. Thanks everyone!
Will it ask for the passphrase every time I commit, as it just did?
Hmm, it even asks for it when I do bzr up...
On Tue, 2009-12-01 at 13:50 -0400, bulia byak wrote:
On Tue, Dec 1, 2009 at 1:39 PM, Ted Gould <ted@...11...> wrote:
My guess would be that when he did the "bzr bind" it resolved to use the 'http' address (non-login) so if he did "bzr unbind" and then "bzr bind lp:inkscape" again it would change the ssh+bzr: URL.
Yes, that worked. Thanks everyone!
Will it ask for the passphrase every time I commit, as it just did?
It uses SSH, so it depends on how you configure your SSH. I have my GNOME keyring caching my SSH passwords so it doesn't, and they're encrypted on disk until I login. Another option is to just use an SSH key without a passphrase. Or, you can also use the command line ssh-agent as well.
--Ted
On Tuesday 01 December 2009 10:53:49 am bulia byak wrote:
On Tue, Dec 1, 2009 at 1:50 PM, bulia byak <buliabyak@...400...> wrote:
On Tue, Dec 1, 2009 at 1:39 PM, Ted Gould <ted@...11...> wrote:
My guess would be that when he did the "bzr bind" it resolved to use the 'http' address (non-login) so if he did "bzr unbind" and then "bzr bind lp:inkscape" again it would change the ssh+bzr: URL.
Yes, that worked. Thanks everyone!
Will it ask for the passphrase every time I commit, as it just did?
Hmm, it even asks for it when I do bzr up...
Make sure you create a SSH key WITHOUT a passphrase if you want a no password experience.
2009/12/1 Joshua L. Blocher <verbalshadow@...400...>:
Hmm, it even asks for it when I do bzr up...
Make sure you create a SSH key WITHOUT a passphrase if you want a no password experience.
Keep in mind this is not 100% secure, because anyone who manages to read your private key file will be able to impersonate you without having to know any password. If you go for this, do not use this key for anything else. Using the Gnome keyring or ssh-agent is the safer method.
Regards, Krzysztof
On Thu, 2010-01-14 at 17:41 -0800, Bryce Harrington wrote:
On Sat, Nov 28, 2009 at 11:08:08PM -0600, Ted Gould wrote:
On Sat, 2009-11-28 at 16:05 -0800, Joshua A. Andler wrote:
I made the first commit on LP after our trunk branch was established and it went smoothly. So, everyone, feel free to go to town!
Yeah! I'll see if I can clean up the GSoC branches a little once I have upload bandwidth again. I think merging trunk into them would make things much simpler.
As a side thought, since 0.48 will be maintained for a bit while 0.49 is under development. What do people think about our use of LP and how we use Fix Released rather than Fix Committed... are people game to perhaps try using Fix Committed (and target them for 0.48 when doing so) for this cycle? If we properly use committed and mark where it will be available, we can then just script it to change to released when it really is (I think it will be nicer for users). Just a thought.
I like "Fix Committed" meaning that it landed on trunk. And "Fix Released" meaning that it's in a tarball. I keep pushing for the script you're talking about there being a button in LP... hopefully it will be soon-ish. Until then, I'm pretty sure such a script already exists.
Hi Josh,
Did anyone end up finding a script to do this? If not, I've coded one up for you for next time (attached).
Hey Bryce,
No, there weren't any found that I am aware of. Thank you VERY much for your work on this!
Cheers, Josh
On Sat, Nov 28, 2009 at 11:08:08PM -0600, Ted Gould wrote:
On Sat, 2009-11-28 at 16:05 -0800, Joshua A. Andler wrote:
I made the first commit on LP after our trunk branch was established and it went smoothly. So, everyone, feel free to go to town!
Yeah! I'll see if I can clean up the GSoC branches a little once I have upload bandwidth again. I think merging trunk into them would make things much simpler.
As a side thought, since 0.48 will be maintained for a bit while 0.49 is under development. What do people think about our use of LP and how we use Fix Released rather than Fix Committed... are people game to perhaps try using Fix Committed (and target them for 0.48 when doing so) for this cycle? If we properly use committed and mark where it will be available, we can then just script it to change to released when it really is (I think it will be nicer for users). Just a thought.
I like "Fix Committed" meaning that it landed on trunk. And "Fix Released" meaning that it's in a tarball. I keep pushing for the script you're talking about there being a button in LP... hopefully it will be soon-ish. Until then, I'm pretty sure such a script already exists.
Hi Josh,
Did anyone end up finding a script to do this? If not, I've coded one up for you for next time (attached).
Bryce
participants (9)
-
Bryce Harrington -
bulia byak -
Josh Andler -
Joshua A. Andler -
Joshua L. Blocher -
Krzysztof Kosiński -
Maximilian Albert -
Nicolas Dufour -
Ted Gould