On Sep 28, 2004, at 5:35 AM, Patrick Smears wrote:
>
> Scott Palmer wrote:
>
>>> Copies don't take more space in the repo.
>>
>> I KNOW that they don't take any (significant) storage space. I said
>> they take an equal amount of space in the repository tree. I.e. a
>> "tag" for a single revision contains an entire subtree with every
>> single folder and file of the folder that was "copied".
>> Stuff that is already elsewhere in the repository and only needs
>> to be "marked"
>
> I guess someone who is unconvinced of the need for "tags" would ask
> why you
> consider this a problem - given that it's never necessary to check out
> the
> entire repository tree, "space in the repository tree" is effectively
> an
> unlimited resource.
>
> Why do you feel that it is a bad thing that this (virtual) tree has
> lots of
> data in it? Granted, if badly organised, it could become confusing to
> navigate - but then, Subversion has powerful ways of organising it. Or
> is
> there another aspect that concerns you more?
I'm not concerned about limited resources - I'm concerned about
presentation. The thing that I want to do when I hit a milestone is
to label the code "this is release 1.0". Branching is a distinctly
different concept. I do NOT necessarily want to fork a branch in the
code repository (though often there will be a maintenance branch).
Since subversion itself does not enforce the read-only concept on the
tag branch there is no difference between this 'label' and a branch...
yet the two concepts are entirely different. Having a tag in the
repository is a nice way to exploit the cheap-copy feature of
subversion, but it is not a great way to implement a 'label' when you
stand back and look at the repository afterward.
If I look at the history of the trunk - do I see the points at which
the 'tags' or 'labels' were made? If not then I am missing exactly
what I attempted to achieve - a label on the line of development at a
certain point in time. Sure, I made a copy at the point in question,
so I can rebuild the project as it was at that point, but now I have
more work to find out exactly which copy that is and where that copy
fits in relation to the trunk. A read-only copy is not the same thing
as an attribute on the trunk. The copy itself, while not wasting
storage space, wastes perceptual space. As I browse the repository
tree those 'tag' copies show up as huge branches tacked on to the tree,
with no obvious relation to what they really mean except whatever
clever naming scheme I come up with. That's a hack, not a 'tag' or
'label'. I could just as easily make a full non-cheap copy at every
point I want a tag or label. Given that disk space is not the issue,
what is the version control giving me here? Remember, I'm not asking
for a branch and don't want or need one. Maybe that is more to the
point. I don't want a branch, I don't care how much it costs, a branch
is simply not what I asked for.
Let me state for the record, that I'm playing devil's advocate here. I
haven't used subversion in a real development environment yet, I'm just
evaluating it. I think that I could live with the way tags work now,
but I see that they are simply not the same thing as a label. A label
is all I need, a cheap copy is far too much really, even though it can
get the job done. (Please don't tell me that it is not 'too much'
because it doesn't take hardly any disk space - I KNOW THAT. Disk
space is irrelevant to my point.)
Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Sep 28 14:57:02 2004