Re: Questions about Subversion Future

On 6/28/05, Greg Hudson <ghudson@mit.edu> wrote:
> On Mon, 2005-06-27 at 22:14 -0400, David Weintraub wrote:
> > It would seem simpler to simply track where a merge took place (from
> > the version of what file on one branch to the version of the same file
> > on another branch). You can think of this information as a pointer
> > from one version of a file on one branch to a version of the same file
> > on another branch.
>
> It's fairly simple to track the state necessary to solve the problem of
> repeated merges of a branch; it's harder if we want to solve
> cherry-picking problems.

Yes, I can see how "cherry picking" makes it much more complex. I just
saw a question on the user list about merging work done in the trunk
to a branch, but skipping one revision which broke the build.

I guess the question is whether "cherry picking" is a required
feature, or is it possible to have a work around. For example,
creating a new branch which is a duplicate of the branch involved with
the merge, but doesn't contain the bad version. If it is possible to
avoid cherry picking, it would make it much easier to do merges in
Subversion.

>
> > * Does Subversion handle directory merging?
>
> It's a desired feature, certainly. Not sure if we have a plan for how
> to get there.
>
> > * There is also a discussion about changing the way moves are done
> > since Subversion treats each move as a "delete and create".
>
> It treats them as "delete and copy" (or "delete and create with
> history").
>
> > I take it
> > that means Subversion doesn't understand that if I have a file
> > http://snv/myproj/foodir/foo.cc and I do a "svn move
> > http://svn/myproj/foodir/foo.cc http://svn/myproj/bardir/foo.cc",
> > Subversion doesn't realize that the foo in foodir is an ancestor of
> > foo.cc in bardir. Is this correct?
>
> No, it understands the ancestry relationship. The problem is more
> subtle than that: because renames look like copies, and you can have
> multiple copy targets for the same file, we can't track a file forward
> in time.

I see... It is very subtle. The advantage is you don't have an evil
twin problem that is the bane of ClearCase administration (see
<http://www.cg-soft.com/faq/clearcase.html#1.2.8>). Once you have
directory merging and true file moving/rename tracking, you open
yourself up for evil twins.

Thanks for the information!

--
David Weintraub
qazwart@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org