-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On May 4, 2007, at 3:57 PM, Stephen J. Turnbull wrote:
> That's right. In my integration workspace maintained under git, I > basically branch for *every* commit back to the XEmacs CVS, and delete > the branch when I see the commit notice. In my sandbox, I have about > 75 branches. I branch for reviewing others' patches, I branch for > typo fixes that can be pushed to mainline immediately. I switch > branches when I fix typos while working on larger tasks, then switch > back and pull the typo. I do the same thing. It's really a fundamentally different way to think about developing software, IME. Since CVS we're so conditioned to the weight of branches that this is a really liberating enlightenment. > I cannot imagine doing that in CVS or Subversion, nor have I yet seen > a ViewCVS of an svn repo that looks like that. But Arch (tla or bzr), > git, and hg repos all have more branches than a centipede has legs, at > least for active projects. It's possible that svk could support that > style, though, since it is decentralized. > > The other question about svn/svk is does it have a rebase operation? > ("Rebase" is from git; it's called "tla update" in Arch, probably the > same in bzr, "patch commutation" in Darcs.) That is, suppose you have > a revision graph > > A --> B --> C mainline > \ > \-> D --> E experiment > > Can it be transformed to > > A --> B --> C mainline > \ > \-> D --> E experiment > > when you realize that "experiment" is not ready for immediate merge? > Or to > > A --> B --> C mainline > \ > \-> D --> E experiment > > if you know that E conflicts with C (either textually, or because > they're different ways to implement the same change)? I've not needed to do this yet, but I can see where it would be a very useful feature to have. Here's what the www.bazaar-vcs.org pages have to say about it. From http://bazaar-vcs.org/ShowStoppers/Samba A rebase plugin would be very nice, with a rebase-push command. It should be used in combination with bound branches. The rebase-push command should try to rollback local commits, then pull all new revisions from the master branch and recommit to the master branch one by one. And then pull the new commits back to the local branch. Maybe a rebase-pull command would do the same but not directly push the local changes, but instead recommit locally. This features seems to be related to patch reordering, patch refactoring and a bzr sync- trees command. See also http://www.kernel.org/pub/software/scm/git/ docs/git-rebase.html. The rebase feature should be only used on integration branches with unrelated patches, so that they don't appear as one big merge revision in the master branch. For feature specific branches normal 'merge --pull' and a final 'push' should be used. > That's really a more important operation to distributed development > than starmerge (unless you're Linus), because it is the fundamental > operation for non-core developers producing the occasional patch or > perhaps a single, long-lived variant (think Richard Barrett's MHonArc > patch). I do something similar all the time, but generally what I do is branch a local "pristine" branch off the mainline branch, then all my dev branches are branches off of pristine. When I need to pull the mainline into a dev branch, I 'bzr pull' the pristine branch to get the tip of mainline, then I merge & commit in any dev branch that I want to rebase to the tip. I've not needed to rebase to anything other than the tip (though I do occasionally have to resolve conflicts of course), but I could imagine that'd be doable by manually specifying a revision to branch from. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iQCVAwUBRjurhXEjvBPtnXfVAQKpWQP/ctmR9pNJqCj4vRJ9jWNltPVvvBpnpUqf Sc0FWtGa3KYdgxsGIMmhXtcusfmUOcu7oeoaFsU3GG3npDbDi6p6SOy5XajjWOla 2DMDNwD7FJTZOW4kKx6ghF7YDDdm1LfMJlGJi6NMQX5h0W++WAOTYrqEOy/rXej4 tC8ff0hKLyo= =Rx3Z -----END PGP SIGNATURE----- _______________________________________________ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp