Re: I, too, miss tags.

On Saturday 25 February 2006 23:56, Duncan Murdoch wrote:

> > I 'svn copy' a "module" to another subdirectory, and play with it
> > there. It becomes yet another "module".
>
> This works ..., but ... In a large project ... will take
> up a lot of space, download time

You are trying to solve nonexistent problems, instead of discussing the issues
about labels/tags which I (and other people) have risen.

I don *NOT* have problems with space, download time, etc -- at the moment. And
when I have them, I *KNOW* how I will solve them. One of the solutions is,
yes, the one you suggest -- to move subdirs one level deeper. But the moment
I stick to my current scheme, since it is more relevant for this project.

> ... That's a better way to work.

There is no "better way". There are circumstances where one or another method
is more appropriate. Having a choice how to implement tags (as labels or as
copies) would be a welcome freedom and would ease the design of repo layout.

There are already many constraints on repo layout (imposed by make system,
workflow, systems limitations, etc.); one more constraint imposed by a
version control tool is nice.

> And if you work that way, then creating a tag is simply a cheap copy
> of the current version of the trunk.

Sure, one can get around the missing labeling mechanism, and I do know how
(please do not cite 'svn cp trunk tags' command -- I know it, and I have even
used it). Just it would be nice to have even better tools (no matter how good
Subversion already is :) -- without the need for workaround.

Again, I do not mean that using 'copies-as-tags' is wrong -- it depends on the
project, team, you personal tastes after all.

(I am forced to skip a lengthy discussion about repo layout and human errors
which IMHO is OT here -- for the lack of time).

> ... a) ... b) ... c) ... d)
> > => e) to mark some state of the project tree which I will want to recall
> > later, I need to mark a revision number, and only it, for a given repo.
> >
> > Tags-as-copies: break d); make c) more difficult; complicate e) since now
> > a revision number is not enough and we need a path as well. However, a
> > need for a path is a consequence of an (overcomplicated) repository
> > layout, which tags-as-copies try to force.

Its a pity that you did not comment on the a-e) issues since they are exactly
about labels and what functionality I expect from them, unlike discussions
about how repo/workflow/etc. could/should be organized... Can I assume that
you agree with all provided arguments?

Regards,
Saulius

PS: Please do not Reply/CC to my address when answering to the list -- I get a
second copy which breaks my filters and "reply-to-the-list" functionality.
Thank you.

-- 
Saulius Gražulis
Visuomeninė organizacija "Atviras Kodas Lietuvai"
P.Vileišio g. 18
LT-10306 Vilnius
Lietuva (Lithuania)
tel/fax:      (+370-5)-210 40 05
mobilus:      (+370-684)-49802, (+370-614)-36366
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org