> (adding the dev list to the reply, since I gathered that at least a portion of the discussion is happening there.)
>
> Saulius Grazulis wrote:
>> On Monday 27 February 2006 03:12, you wrote:
>>> Personally, I think that it was a stroke of genius to realise that
>>> the filesystem can already capture most of the information you're
>>> interested in
>> Agreed :)
>>
>>> (collections of interesting elements mainly). The
>>> Subversion guys have added finer grained information and efficiency
>>> on top of that, end of story.
>> In my view, (mis)using of directories for taging version is a
>> deviation from this brilliant concept of "filesystem with history".
>> This adds a special directories that are meningless for the project
>> (i.e. tags/), but which must be present in order to get tag
>> functionality somehow.
>
> 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.
And in both cases you might want to version control such operations.
Furthermore, you want to have hierarchical namespaces
both for branches and tags.
So I think it is very natural to use the versioned filesystem
both for branches and tags.
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?
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.
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.
Cheers,
Folker
---------------------------------------------------------------------
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:09:33 2006