-----BEGIN PGP SIGNED MESSAGE-----
On Sep 27, 2004, at 9:16 PM, Scott Palmer wrote:
> On Sep 27, 2004, at 11:17 PM, Tom Mornini wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>> On Sep 27, 2004, at 7:19 PM, Scott Palmer wrote:
>>> 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 for one understood your comment the first time, though I almost
>> misread your comment as Bryan Donlan did. In fact, I wrote a response
>> not entirely dissimilar to his.
>> But, since only the copied node is stored, though it LOOKS like it
>> 'takes space in the tree'
> In the paragraph above the last you claim you understood my comment,
> and then go on to repeat what I already know and have tried to explain
> twice already - that I know that the copies are cheap. You did not
> understand, you missed the point entirely.
No, I understood it. I just forgot a colon at the end, and instead
placed a paragraph. :-) That was the response I began writing when I
first misread your sentence.
> The tree is what it looks like, those nodes that are cheaply copied
> ARE part of the tree, they show up in every rendition of the
> repository tree and can be operated on as any other node in the tree
> be it an 'original' or a 'copy'. If you drew a graphic representation
> of the entire repository tree the copied tag would take as much space
> as the original in terms of number of nodes and depth and all that...
> the tags would take up space in your rendition of the repository - yet
> a mark on a particular version (an alias for a revision perhaps) would
> NOT take up space in the rendition of the tree. In short the tag
> doesn't "LOOK" like it takes space in the tree, it does take space in
> the tree.(It just doesn't take disk space in the repository.)
But...I still simply cannot get my thick head about your concern for
the "cleanliness" of the tree. You say they "show up" in every
rendition. Conceptually, yes, but physically how? And, yes, I
understand that you don't have this problem personally, but how do you
imagine others see it?
If you need a list of the tags, just issue 'svn ls root/tags' and you
don't see the entire tree, you see just the tag names. How is
this a mess, and how does it take a lot of space?
>> (and subdirectories and files certainly appear as leaves on the
>> tree) it really only is a mark that can be navigated spacially.
>> In essence, they ARE only marked. They're no more copied or taking
>> space than your reflection in a mirror!
> They are NOT only marked, they are real nodes that work as any other.
> But it is a good analogy - try finding what you want in a hall of
> mirrors :)
But it's NOT a house of mirrors in that respect. If you need the names
of the tags, just look at the tags area! It's not as though 'svn ls' is
recursive by default.
>> If you don't need to see the subtrees (check out the trunk!), and
>> they don't take space, then why be concerned about it.
> I would see them them IN the repository, I know I don't have to check
> them out into my working copy, that isn't at all what I'm talking
> about. It is the clutter IN THE REPOSITORY that is the issue, and to
> be honest I don't really know that it is an issue for me personally,
> but it is part of the point about the request for non-copy markers in
> the repository.
You cannot (until recently at least) SEE them in the repository!
They've been in the BDB. Why in the world would anyone concern
themselves about the backend storage format in a system with
Honestly, we all agree on the need for tags. How gives a damn how
they're PHYSICALLY or LOGICALLY stored in the backend?
- -- Tom Mornini
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)
-----END PGP SIGNATURE-----
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Tue Sep 28 19:48:31 2004