On 2006-02-26 00:39:36, Saulius Grazulis wrote:
> On Saturday 25 February 2006 12:24, Max Bowsher wrote:
>> * Unversioned: You can't tell who or when 'aliases' were created, nor
>> track the history of an alias that undergoes changes.
> Wrong, you can easily store a committer and date along with the label:
> "VERS-2.2:rev12345:saulius:2006-02-26: etc. etc."
And what exactly is the point of repeating this versioning
functionality when you already have it available in the
filesystem? All the information you've presented in your
example just there is already captured by the "svn cp" process.
>> * Unscoped: It would be far too easy for multiple
>> projects in the same repository to clash on their alias naming.
> Wrong, it is as easy (or as difficult) as not to clash directory
> of file names for the multiple projects.
If that is the case, then what advantage does your approach have?
If there are multiple projects in a repository, or any need for
multiples of the same alias to be created, then you'll have to
separate them using some kind of namespace. We already have a
useful namespace in the filesystem. e.g. projectA-ALIAS1, doesn't
that look suspiciously like "/projectA/ALIAS1" which can already
be stored in the filesystem?
> Not to mention that I find putting multiple (unrelated)
> projects into one repository strange and inconvenient. Bu
> this is again a matter of personal preferences.
In CVS, it *is* inconvenient, because you have the lack of
versioning and namespace conflicts that arise. Using Subversions
recommended model, you don't have these problems and it turns
out that it's quite convenient to have many projects in one
repository (just look at http://svn.apache.org/viewcvs.cgi/)
>> And, most of all, there is the conceptual weirdness of having two
>> totally different UI paradigms for supporting the same goal.
> Wrong, there is a conceptual weirdness in misappropriating
> branch mechanism and special ad-hoc agreements (like "use
> 'branch/tags/main' repo layout") to emulate missing tags.
So how do you resolve the situation where someone has chosen
to create an alias called "FOO", and someone has created
a "/tags/FOO"? Which one wins? It really wouldn't be a good
idea to have two mechanisms to solve the same problem.
> Taking it to the extreme, you could equally argue thatg
> version control was possible long before Subversion, and
> long before any other VC tool for that matter:
>
> cp -a project/trunk ChangeLog project/revision-1234
>
> so Subversion should be considered obsolete.
> onceptually, Subversion does the same thing, if you want. It is the
> efficiency and convenience that we gain by using Subversion. So
> naturally there is a wish to straighten all remaining "rough edges".
Well done, you've finally worked it out. Yes, Subversion is saying
that you *can* do version control like that, and there's nothing
wrong with it, it works great! What Subversion adds to this is:
1) Revision history, so you can list fine-grained changes to
versioned elements.
1) Copy history, so you know how tags/branches are related to
each other.
2) Sparse storage, so you don't waste lots of space.
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 (collections of interesting elements mainly). The
Subversion guys have added finer grained information and efficiency
on top of that, end of story.
daniel
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Feb 27 02:13:12 2006