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

Re: question relating SVN file/directory merges and tree conflicts

From: Stefan Sperling <stsp_at_elego.de>
Date: Wed, 22 Jul 2009 15:56:50 +0100

On Wed, Jul 22, 2009 at 10:28:04AM -0400, Bob Archer wrote:
> From the outside looking in, would it make more sense to provide a
> surrogate key/name to each versioned object so that is can be
> uniquely identified in the repository without relying on the full
> path as the name?

A path plus a revision already gives you a unique key.
There can only be one object at a path in a revision.

Also, I think the filesystem already uses node IDs internally,
but I'm not quite sure cause I never had to look at that part
of Subversion yet. The naive approach to implementing moves
would cause clashes with these node IDs.
See http://subversion.tigris.org/issues/show_bug.cgi?id=898

> > On the way, we'll either reach 2.0 and stop being backwards compatible,
> > or we will have to invent ways to keep all this compatible with the
> > way things work right now.
>
> Personally, I would say don't worry about backward compatibility. Make
> this a 2.0 feature.

The problem with 2.0 is that it might invalidate a lot of the
ecosystem that has grown around Subversion. Many projects (e.g.
TortoiseSVN) have written tools around our APIs, and we'll make
it very hard for them if we stop being backwards compatible.
IDE integrations will stop working if they're not updated, etc.

> Although figuring out how to populate this info
> during the upgrade is problematic. Perhaps some type of --record-only
> feature like you have for merge data so that I can specify the
> move/rename ancestry of various objects manually.

You can easily reconstruct move information today.
It's just computationally expensive to get at it, because
Subversion only provides copy information in one direction.
This also hurts applications such as revision graphing.

You can reconstruct move information by following all copyfrom paths
in the repository backwards to their origin, and then inverting that
relation. This is how e.g. trumerge tracks renames
(http://trumerge.open.collab.net).

Stefan
Received on 2009-07-22 16:58:07 CEST

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.