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

Re: Moving C to its own directory (was Re: ObjC tree inlining)

From: <peter.westlake_at_arm.com>
Date: 2001-11-22 10:30:04 CET

...
>There have been various proposals for a Subversion module system,
>along the lines of "union directories", or other indirection-based
>systems that allow rule-based groupings. That would probably solve
>the problem described above, but it will not be in 1.0.
>
>On the other hand, Subversion will support symlinks / shortcuts, which
>should alleviate the problem...
>
>-K

I guess you mean it will store Unix symlinks or WIndows shortcuts,
and similiar things, but just in case you were talking about the
proposed Subversion vlink/reference feature, "svn ln", here's an
observation.

If you implement this by storing the path to the target, it will
get out of date as soon as the target is renamed. Broken links in
the repository are clearly a bad thing. So you would use a node id
instead. The problem then comes if you copy the target (svn cp), so
that two nodes in the repository DAG point to it. You can check in
to either the copy or the original, making a new node. Suppose the
original target node has node revision id "T.3". The new node will
be "T.4", whether it is created by a checkin to the original or the
copy. Checking in to the other path (copy or original) will make a
node "T.3.1.1". The point of all this is that you can't tell from
the node [revision] id which node your link is meant to point at.

Peter.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:49 2006

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