[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: Bob Archer <bob.archer_at_amsi.com>
Date: Wed, 22 Jul 2009 10:28:04 -0400

> Sorting this issue out is a long journey.
> Right now, the working copy is being rewritten.
> This will, among other improvements, allow is to track renames on
> the client side more reliably.
> But then, we'll also need to propagate rename information to
> the server. The programming interface we use to send tree changes

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? This way you can easily tell that if the full path of objectid A13ED4 (for example) changed that it was moved/renamed. At this point a change to the "full path" of the object could be either a rename or move. But, I don't think that even matters.

As you can tell I come from a db application background and this is exactly why we use surrogate keys rather than rely on the user data to be the key.

Granted, I know this wouldn't be a small change and probably is more of a 2.0 issue since it needs alot of planning an co-ordination.

But, if something like this is done it seems like the foundation can be laid in WC-NG db design. Providing a surrogate key in the client side .svn database. An "add" could gen a new key for the object. Of course, if this isn't stored in the repository it can't be populated on a check out (yet).

> 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. 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.

> So we're really talking about changing several major parts for
> Subversion's design and then changing the code base accordingly.
> Guess how many active developers we have at any given time?

No doubt it is a big project, and I have the utmost respect for the svn devs. I wish you the best in this endeavor.



To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-07-22 16:29:02 CEST

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