"Sergey A. Lipnevich" <sergey@optimaltec.com> writes:
> I think one variant is missing, although I didn't follow the whole
> thread so it might have been dismissed already: using the same idea as
> with tags/branches. Here's what I mean. We have tags/0.20.0 and
> tags/0.21.0, and this is how released versions can be browsed. We
> could have revs/123 and revs/456 doing the same thind but for
> revisions. You may say that it's available now if somebody decides to
> create a tag for every revision, and I'd agree. The trick is to make
> Subversion server do this automatically on every revision, so that
> creation of revs/9876 is part of revision 9876. The path starting from
> revs/ should probably be made read-only though, otherwise making
> changes inside rev/9876 will be difficult to explain: wow, I can
> change this revision 9876 which was made twenty revisions ago to have
> some other data? Of course the answer is no.
> I think this might work best because copies are cheap, and will hardly
> require any major changes both in the code or in thinking.
Hm... my brain isn't fully wrapped around the implications of this,
but my initial thought is -- "Whoa. That's cool."
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Aug 6 21:35:55 2003