Scott Palmer wrote:
> I think it is more that it clutters the tree. I know the disk space
> isn't an issue, but a copy takes up just as much space in the repository
> tree as the original. I don't care about disk space, because the
> repository isn't even on my disk -it's on a server that has plenty of
> space. But either you have tons of 'tags' folders all over the place,
> or a few 'tags' folders full of all sorts of stuff that I don't really
> want to see most of the time. And as noted in #2, they don't show up in
> some places where it would be very useful to see them.
>
> As a general mechanism for marking a revision, I have no problem with
> the underlying "cheap copy" implementation. It is the presentation
> (identical to that of a branch except that we gave it a special name)
> that I find a bit awkward.
Scott and Brad got it right. IMO its not the space or some other
resource issue that bothers some people, its about presentation of the
revisions and the perception how a revision should be managed. Perhaps
its also a feeling that this copy mechanism behaves like a workaround,
while mostly doing what most people need, its doesnt get it completely
right. Brad explained that very good.
For me, a revision is something inlined into the repository, without any
representation other than a defineable mark. Something you can check out
on demand, and something you can query easy for. To think again about
it, the presentation issue is the one that matters most to me.
--
regards
Marc Logemann
http://www.logemann.org
http://www.logentis.de
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Sep 28 00:31:29 2004