On Thu, Feb 22, 2001 at 10:10:56AM -0600, cmpilato@collab.net wrote:
> Jim Blandy <jimb@zwingli.cygnus.com> writes:
>
> > I'm not sure I really understand the technique he's suggesting.
>
> I'm not totally sure either, but it looks as if the end result is a
> single working copy with some files saying that their ancestry lies in
> the main tree, and some claiming heritage in a branch of that tree.
> Those in the branch are the works in progress (an API rewrite, as the
> example goes). I'm not sure if I grasp the article-inspiring
> brilliance in all of this, though.
I think the idea went something like this:
You want to do some radical development changes on a small portion of
the tree. But you don't want the rest of the tree to fall behind the
mainline. So you have <files-to-be-frantically-hacked> from the
branch in CVS, and <other-people's-problem> from CVS HEAD.
This can of course be done manually, by applying all the changes made
to head to the branch. Or probably with lots of scary merging. But
Luke's solution is O(1), so to speak.
This is actually a use-cse that I think subversion could support in a
more elegant way. Lots of branches are created in repositories for
radical development on one part of the repository. However, it
doesn't make any sense for the changes on the trunk not to be merged
in (it's not like it will become more unstable, or something). And
doing this merging each time will make the final merge, once
cool-new-feature is done, significantly easier.
So maybe there could be an option to svn branch like this:
$ svn branch --keep-this-up-to-date-with-the-mainline foo foo-branch
This would reduce the need for workarounds like Luke developed.
sam th
sam@uchicago.edu
http://www.abisource.com/~sam/
GnuPG Key:
http://www.abisource.com/~sam/key
- application/pgp-signature attachment: stored
Received on Sat Oct 21 14:36:23 2006