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.
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,
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
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].
This is an archived mail posted to the Subversion Users mailing list.