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