Re: I, too, miss tags.

On Saturday 25 February 2006 17:00, Duncan Murdoch wrote:

> It doesn't say anything about how you construct your working copies, but
> it does say that if you want multiple branches of your project, they
> need to be in separate non-nested directories. That's fundamental to
> its design.

My understanding of Subversion is that each repo keeps history track of one
file tree. What is inside that three does not matter (or should not matter)
for Subversion. This is even declared in the Subversion book. Right?

> The way you've chosen to use it makes it impossible for you to have
> multiple branches. That's one reason why you shouldn't do that. You're
> cutting yourself off from some useful functionality.

No, I can happily have multiple branches.

As it happens, I keep all modules (i.e. related sets of source files) in
separate subdirs, right on the top of the repository. Whenever I need a
"branch", I 'svn copy' a "module" to another subdirectory, and play with it
there. It becomes yea another "module".

Again, I have already mentioned that I love Subversions branches. And if
needed, a repo can be reorganized to have trunk/ and branch/, and then
flattened again -- as necessary ;). And the tags should remain intact during
such operations. So the issue is about tags.

> I think they'd save you a little bit of trouble, but they'd cause more
> in the end, because people would commit experimental code during testing
> for a release, etc.

If we assume such setting then the people would happily (try to) commit to a
'trunk' during the testing phase.

Even worse, they will try to commit to tags as well. Thats one of the reasons
why I think tags-as-copies are inconvenient.

> People make mistakes, and svn is a good tool for
> stopping those mistakes from having worse consequences than necessary.

No tool will ever stop people from doing wrong things, and I do not see why
consequences of tags-as-branches will be any better. On the contrary, it is
easy to mess up the tags/ dir, but if a released version is reliably marked
as a revision label (probably immutable one), then who cares? It can always
be restored *from that specific revision*, and *only from it*.

> You want to force the
> repository to be used in a strictly linear fashion, while the normal way
> is more structured.

Well, my understanding of (Sub-)versioning process is following:

a) Subversion keeps track of the whole filesystem tree in a repository.

b) Each history point in the life of the tree is marked by a sequential
number, a revision number.

c) Revision numbers, and only they, allow me to move "back in time", restore
old revisions, merge parts of their contents into new files and so on. I can
not work without them, with tags-as-copes or without them.

d) What is inside the tree, is a matter of the make workflow, layout of the
source tree, etc. This layout *should not* matter for the version control
system.

=> 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.

Tags-as-revision-names would solve all the above issues in a simple (and
elegant? ;) way.

Note that trunk/branch/main/release/tag layout can happily be used with the
labels if someone wishes so. This is a layout of the repo, and it is an
internal matter of each project how to choose it. And I believe labels would
complement this mechanism in a fruitful way.

Just my thoughts,
Saulius

-- 
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