[Python-Dev] Looking for VCS usage scenarios (original) (raw)

Barry Warsaw barry at python.org
Mon Nov 3 23:54:43 CET 2008

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Nov 3, 2008, at 4:56 PM, Brett Cannon wrote:

But then again, having one scenario that shows svn's weakness directly wouldn't hurt. I could see a scenario where I start to fix something in branch A, realize that a deeper issue needs to be fixed, leading to branch B, and then have branch A depend on branch B. Is that possible?

This is something I do all the time with bzr. A related workflow is
one where you're developing several inter-related dependent branches.
In those scenarios, I personally find Bazaar looms indispensable. I'm
told that bzr looms are similar to hg quilt.

Until I started using looms I had no idea of their power and
transformative effect on my code development. This is one of the
problems of coming up with scenarios: you don't know what you're
missing.

Or is injecting branch dependencies like that not workable? If it doesn't work, then a branch A/B that a branch C is dependent on would also work as a scenario (e.g. reworking the testing framework where you are doing a bunch of different things at once that are culminating in a single new testing branch that collects everything).

Those sound like what you are getting after?

Let me try to describe a scenario and see if it fits what you're
looking for.

I'm fixing a bug in urllib2.py when I realize there's a lower-level
bug in base64.py. I'd like to cleanly suspend my work on urllib2.py,
then "push my stack" to start working on the fix for base64.py. Half
way through that I realize there's also a bug in binascii that I need
to fix. I'd now like to "push my stack" once more to fix the binascii
problem.

Now that binascii is fixed, I'd like to pop my stack to complete the
base64 fix, but without losing all the changes I made to binascii.
Similarly, when I've fixed base64, I want to retain those fixes and
pop my stack back up to urllib2.

I've now got three related fixes. Do I get each reviewed
independently or together? Do I land them independently or together?
Can my dvcs help me manage all these inter-dependent branches?

For bzr, the answer is "yes" and my own workflow to handle this uses
looms, which you can think of as a kind of "stacked branches"
approach. Each layer in the stack is called a "thread" and I can
easily create new threads in the stack. So I might approach the above
scenario like so:

bzr branch trunk issue1234 cd issue1234 bzr loomify --nick trunk bzr create-thread urllib2-fix

hack hack hack, oops! gotta fix the bug in base64

bzr commit -m'Fixes to urllib2 so far' bzr down-thread bzr create-thread base64-fix

hack hack hack, oops! gotta fix binascii

bzr commit -m'Fixes to base64 so far' bzr down-thread bzr create-thread binascii-fix

hack hack hack. ah, all is good

bzr commit -m'Fixes to binascii' bzr up-thread

At this point, all my binascii-fix changes are merged in

resolve any conflicts that arose and commit, then finish

hacking on base64

bzr commit -m'Fixes to base64' bzr up-thread

At this point all my binascii-fix and base64-fix changes

are merged in. resolve any conflicts that arose and commit

then finish hacking on urllib2

bzr commit -m'Fixes to urllib2'

Here's what's even cooler. Let say, while I was working on all this,
someone landed a change to trunk that I want in my branch. I can 'bzr
down-thread' to the lowest thread (i.e. trunk), pull in those changes,
and then using 'bzr up-thread' merge them into all the threads above.
Then I go back to hacking.

There are all kinds of scenarios based on this one, and I hope the
above makes sense. It's things like this (and 'bzr shelve') which
make using a dvcs like Bazaar so nice.

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSQ+BNHEjvBPtnXfVAQLLrwP/aJuetZxYI0S0SvT5QXJG6wARI2K9vdc5 zpUMHofCkxAq4tv/2Ni7g46jUNTayH4A94sAUqjE0QPM3SFl22/TNjga4ZgaHdjt 7Ma9iX7+s5OJenvV0kd3ReN6KvcKQhcQZ+P4DkWBJu0KDxGptUk/WGer3aDdQNzV jn88QaHpEBk= =fPRR -----END PGP SIGNATURE-----

More information about the Python-Dev mailing list