[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Faulty merge logic?

From: <kfogel_at_collab.net>
Date: 2005-06-12 02:02:54 CEST

Ben Collins-Sussman <sussman@collab.net> writes:
> On Jun 8, 2005, at 12:32 PM, Carl Youngblood wrote:
> > Forgive me if this has already been posted to this list, but I
> > recently came across a blog entry considering different version
> > control systems:
> >
> > http://www.simplicidade.org/notes/archives/2004/11/
> > evaluating_sour.html
> >
> > One section especially caught my attention:
> >
> > "While evaluating these systems, I developed a small test to see if
> > it's good enough for me:
> >
> > create two branches of a project, called B1 and B2;
> > modify file X in B1;
> > in B2, rename file X to Y;
> > merge B1 into B2.
> > If after these simple steps, your Y file does not have the
> > modifications made in B1, the source control system is flawed, and I
> > just can't use it. If you are serious about source control, this is
> > just not acceptable.
> >
> > The interesting part is that it seems Subversion fails this simple
> > test. I think I'm doing something wrong, I'm trying to see what, but I
> > can't get Subversion to do the right thing. This would remove it from
> > my list, and I would like to use Subversion (JabberStudio uses it a
> > lot now)."
> >
> > Is this still true, and if so, is this a valid complaint, in your
> > opinion?
>
> Subversion doesn't have true moves, it has copies and deletes, and
> the server currently doesn't broadcast copies to the client. We're
> working on fixing it, mainly by implementing true moves.
>
> In the meantime, here's another similar issue that explains what
> you're seeing:
>
> http://subversion.tigris.org/issues/show_bug.cgi?id=2282
>
> In other words, the server is sending a delete + add, rather than a
> move.

This problem has nothing to do with true renames or the lack thereof.
Even after Subversion has first-class renames, this problem will still
exist.

The behavior described above is one of the many things covered by the
term "merge tracking". The files are in different branches, and since
Subversion's merge command currently operates by name, not by object
identity, it wouldn't follow the rename. In other words, making
renames *preserve* object identity is not the same as making changes
*follow* object identity. Fixing this would be a fine thing, and is
on Subversion's long-term roadmap.

> > If after these simple steps, your Y file does not have the
> > modifications made in B1, the source control system is flawed, and I
> > just can't use it. If you are serious about source control, this is
> > just not acceptable.

The first assertion ("I just can't use it") is not something we can
argue with, obviously. The second assertion is mere chest-beating in
the passive voice. We're quite serious about source control, thank
you very much, but our priorities may not be the same as yours.

-Karl

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sun Jun 12 02:45:58 2005

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.