Folker Schamel wrote:
>> I have to say, my complaint is that people advocating the
>> "trunk/tags/branches" structure are advocating using paths to store
>> revision information, which is nonsensical to me.
>>
>> Having current development code in trunk makes sense--it's a
>> specific location in the directory structure, proceding forwards
>> through time. Similarly, branches are copies of specific locations,
>> which exist for some (unspecified) period of time. Tags, by
>> definition, however, are supposed to be "snapshots" of at least a
>> portion of the repository at a specific moment in time, and are not
>> supposed to be mutable. Tags are inherently different from
>> branches, and ought to be treated as such.
>>
>> Trunk and branches are paths for development, and it makes sense for
>> them to be treated as such. Tags, however, are not--and so they
>> should not be. Seems simple enough to me.
>
> The only difference between a branch and a tag I can see is
> that the content of a tag is usually immutable.
> Otherwise they share several things.
> For example, both branches of tags are mutable:
> They are created, re-defined and destroyed.
Ok, I'm confused. Tags are immutable, but they're mutable? To my mind,
a tag is not mutable--once created, it should not (at least 98% of the
time) be updated, and there shouldn't be any reason to remove it.
(You'll note that my original proposal required an explicit '--force'
option to alter a tag, specifically to enforce the idea that it should
not be mutable).
> And in both cases you might want to version control such operations.
> Furthermore, you want to have hierarchical namespaces
> both for branches and tags.
Why would you want hierarchical namespaces for tags? There's no
hierarchical namespace for revision numbers. And, frankly, the thought
of 'svn co -r proj1/releases/1/2/8 svn://example.com/repos/proj1' scares
me. The goal was to reduce confusion, rather than increase
opportunities for it.
> So I think it is very natural to use the versioned filesystem
> both for branches and tags.
I don't. Tags refer to a specific moment in time, rather than files on
the drive. Moments in time don't change, at least not with our current
understanding of time.
> My impression is that at the end you want to go backwards in time
> to the more limited CVS model, because you are used to it,
> but giving up the above advantages?
No. I want to give the users the _option_ to use the tool in a way that
makes sense, using paths to track path information, and labels to track
time. I love SVN's branch mechanism; it just doesn't make sense to use
it for tags--it's using a bazooka as a fly swatter. Too much power, and
not designed for the task at hand.
> Furthermore, even if some things would be inherently different,
> then this does not mean that they must not share the same underlaying
> mechanism. For example, text files and bitmap files are inherently
> different,
> but both are stored in files.
Yes, they share the commonality of being files. Branches and tags don't
share that sort of relationship. Branches are mutable, on-going
alternate development paths; tags are (supposed to be) at least a
section of the repository at a specific point in time--which is to say,
a specific revision. You can kludge this by copying that section off
somewhere and putting a "do not touch" sign on it, but there's no
built-in guarantee that that will happen; on the other hand, recording
the revision number is guaranteed to fulfil this through anything short
of a dump-filter-load process (and could even be designed to survive
that).
> Of course, you can discuss about the user-interface,
> for example that when using the SVN command line clients
> that you have to type more than in CVS.
> but this is a different issue than the architecture.
I agree that's a different issue, and has never been part of my
argument. Why bother bringing it up?
-David
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Feb 27 18:55:44 2006