Hi all,
long time lurker and (if i remember correctly) first time poster.
Just yesterday i was going through some mails from january i hadn't read
at the time because of lack thereof. When I saw the discussion of
MOVE=COPY+DELETE again, i remembered an idea i had a few months ago,
which might be an interesting take on the issue. (Talking of which, i
didn't find an issue about this and haven't seen it on the ML, so i
assume this idea is new - my apologies in advance if this has already
been proposed/discussed.)
_Suppose_ we had the concept of an in-repository hard-link. (I think
somebody brought that up before). That is, if a and b link to the same
thing, everytime i commit to a, an update would change b aswell. (a and
b in the wc might even be hardlinked too, if the underlying OS supports
this - but that's a completely different issue.) [1]
Now a MOVE could be represented as a LINK+DELETE, instead of COPY+DELETE
(with the LINK having the appropriate LINKFROM parameter). This would
still preserve the possibility of discreetly commiting each end of the
MOVE (partial commit), while putting the resulting file in better touch
with it's ancestry, should work rather well when merging somebody else's
changes, giving us IMHO more robust MOVE semantics (in terms of what
happens vs. what users expect), and fries with that.
(One special case i can think of that would be needed is a LINK where
the LINKFROM source has already been deleted. This could just point the
LINK to the last existing revision of that file, which is IMHO also a
sensible semantic outside the MOVE case.)
Now i know that in-repos hard-links are a biggie (and probably evil),
that nobody has time to implement all this, especially right now, and
that there's also the maybe even better option of truly atomic moves.
Which is why all i'm intenting with this mail is to put the item out for
discussion. Maybe something worthwile will come out of it.
Bye,
Philipp
[1] A (possible) idea on how hard-links could be implemented:
Quoting Branko's example from the aforementioned thread:
> I'll try to illustrate the point. Imagine you have two directories "A"
> and "B", that are children of the root. "A" contains the files "foo" and
> "bar", B contains "qux". I'll tag each node with its node revision number:
>
> / (0.0.4)
> A/ (a.0.3)
> foo (f.0.2)
> bar (r.0.3)
> B/ (b.0.4)
> qux (q.0.4)
>
> To understand this example, you should be aware that, within the file
> system, directory entries are nothing but named pointers to node
> revisions (those "a.0.3" triplets); the names are not a property of the
> node revisions themselves.
To link A/bar to B/baz, we would need a thing (like an inode) where both
A/bar and B/baz can point to, which in turn would point to (r.0.3), or
(r.0.5) after the next commit.
Another layer of indirection. *sigh*
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Mar 7 00:54:43 2003