Questions about Subversion Future

[David Weintraub <qa...@gmail.com>]

I read the technical development document for Subversion and have a
few questions. It might be that these question have already been taken
care of (since I was warned that the technical document is out of
date).

* There are plans for Subversion to have a file track all predecessor
versions to help improve Subversion merging capabilities. The
discussion sounded interesting, but the proposed structure sounded
fairly complex since each version of the file must know all of its
ancestors and in order to do a merge, you must got through both sets
of ancestors to do the merge.

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.

Re: Questions about Subversion Future

[David Weintraub <qa...@gmail.com>]

On 6/28/05, Greg Hudson <gh...@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

Re: Questions about Subversion Future

[Greg Hudson <gh...@MIT.EDU>]

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.

> * Does Subversion handle directory merging or are there plans for
> Subversion to be able to merge directory structures? I didn't see
> anything in the technical documentation about this.

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.  (We also lack an efficient mechanism to track a file forward
in time, but the semantic problem is the foremost one.)

> The same is also true with rename operations?

Move and rename are the same thing.

>  I understand that you should be able to look at the log
> and guess what happened, but Subversion itself won't give you a
> complete history of a file if it was either moved or renamed. Is this
> correct?

You get a complete log unless you use --stop-on-copy.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org