David Waite <mass@akuma.org> writes:
> cmpilato@collab.net wrote:
>
> >Ah, now some implications are coming to mind. The most obvious is
> >that we are robbing Subversion users of the ability to make their own
> >top-level directory named 'revs', which they may want to do. But more
> >annoyingly, from an implementation standpoint, we introduce a cycle in
> >our DAG, and trying to write special-case code for untangling that
> >cycle, as well as for "write-protecting" that directory, is a
> >non-starter. So, despite the neat-O result, -0.9 for cost.
> >
> My brain is probably not completely wrapped around this either, but
> why does this introduce a cycle in the DAG? Can you give an example?
/revs@REV is a child of /@REV, and yet has an entry named "REV" that
points to /@REV. That's a cycle. :-)
To avoid the cycle, you'd need each commit to become two commits, one
to implement the filesystem changes, and one to create the /rev/REV
"tag". Alternatively, you could combine several of these "tagging"
operations into a single commit. But the point is that you can't
currently make a copy of something that hasn't been committed,
therefore you can't make a tag from something that hasn't been
committed, and even if you *could*, you have no idea what the new
revision is (and thus no way to actually name the entry in the /revs
directory) until the commit succeeds.
Unless, of course, this proposal was not about using a real filesystem
tag, and was instead about manufacturing a sort of faux directory
named /revs. In which case, you can pretend that I wrote all of this
in ALL CAPS AND HTML and can discard it as spam. :-P
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Aug 6 22:30:29 2003