On Monday 27 February 2006 03:12, you wrote:
> > 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
You asked for it, and I demonstrated how this can easily done. Sure there is
no real need for this :)
If we use versioned properties for labels, revisions already store user and
date with a commit information. Thus, only "VERS-2.2:rev12345" are essential.
> All the information you've presented in your
> example just there is already captured by the "svn cp" process.
As said, unix 'cp -a' also "captures" the information, just for some reason
people want Subversion to manage revisions... => That it captures some
information is not enough. It must be flexible and convenient to work with.
> > 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?
Flexibility, simplicity, versatility and convenience of use. No more no less.
> 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?
One of the questions I am interested in is "in what state was sub-projectA
when sub-projectB went to release-1.2?". This is exactely the sence in
requesting 'svn update -r PROJ_A-VER-1.2 project-B-WC/'
> 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/)
I did it once and regret it. Now I have an overbloated repository which I can
neither reduce (no 'svn obliterate') nor split (because 'cheap' cross-copies
between the subprojects cause 'svnadmin load' to fail when I remove source
branches from the dump). I can not say that I find it damn convenient :/. But
it still works, so everything is fine, I don't comlain.
OTOH, all one-repo-pre-project things are just fine. So I always create a new
repo for a new project.
> 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.
The apparent conflict arises only because you are so deeply entrenched in you
"/tags/FOO is a tag" approach that you always implicitly assume it.
"/tags/FOO" is just another directory in a repo. No special meaning needs to
be attached to it any more, when labels are in place. You can call it
whatever you want, all similarities with version tags are purely accidental.
To get version tagged "FOO", you get a revision associated with "FOO". If you
need, check out the whole repo. If that is too big, check out a subdir at
FOO. Simple. Clear.
> 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.
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.
PS. Sorry for possible double posting, but I am not on the dev list, and part
of this thread I get from users list which I am not sure you are on...
Dr. Saulius Gražulis
Institute of Biotechnology
tel.: office: (+370-5)-2602556
mobile: (+370-684)-49802, (+370-614)-36366
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Mon Feb 27 08:47:13 2006