W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > October to December 2001

RE: Why does MERGE automatically checkin resources related to act ivities?

From: Clemm, Geoff <gclemm@rational.com>
Date: Thu, 4 Oct 2001 09:03:55 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B10475D94D@SUS-MA1IT01>
To: ietf-dav-versioning@w3.org
I've got a few more questions for Greg about the subversion model (so
that I can understand its mapping to DeltaV).  This thread may be
drifting a bit off topic though, and if so, please send me private
email and I can redirect it to a subversion mailing list.

   From: Greg Stein [mailto:gstein@lyra.org]

   Purely sequential, global revision numbers. Each revision is
   effectively a baseline for the whole repository. No branching; just
   work on stuff in a different "subdirectory" within the virtual
   filesystem.

Does subversion allow you to "merge" that work in a different
subdirectory back to the directory where they came from?  For example,
if you do:

 CHECKOUT /repo/proj/
 => /repo/wr/173

 COPY /repo/proj/projA
 Destination: /repo/wr/173/my-projA

 CHECKIN /repo/wr/173/my-projA

You've now got a copy of projA in /repo/my-projA.  You can now make
changes to my-projA independent of changes to projA.  But you cannot
use MERGE to merge the changes from my-projA back to projA.
Whereas if you had used a sequence of VERSION-CONTROL requests to
create /repo/proj/my-projA, you could merge my-projA back to projA.

   > I thought it was a fairly central CVS feature to create a new "branch"
   > of the repository, to do a whole series of checkins on a branch, and
   > then only merge that repository branch on demand.

   Because CVS sucks so hard at the merge process, nobody ever uses
   branches for temporary hiding of checkins. They are normally just
   used for longer term branches.

Yes, I totally agree that you don't want to create a branch for every
change.  In the normal case, you just checkout into some activity the
files you want to change, muck with them for a while on your client,
update the working resources, and then MERGE your activity back to the
repository.

What I was really asking about was those cases where you actually do
want to run in parallel for a while (i.e. doing early dev work on a
new release while the current release is being stabilized), but where
you want to periodically merge work between those parallel streams.
Is that going to be supported by Subversion?  And if so, how did you
plan on marshalling the creation of the parallel area, and the merge
back?

Cheers,
Geoff
Received on Thursday, 4 October 2001 09:04:34 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 13:57:42 GMT