[Python-Dev] Looking for VCS usage scenarios

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.

- -Barry

-----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