-----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-----
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
