On 2/25/2006 4:25 AM, Saulius Grazulis wrote:
> 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?
Yes.
>> 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".
This works for a small repository, but is quite inconvenient on a large
one. Assuming that, as you said before, you normally have the root of
the repository checked out, then you end up with a full copy of each
branch in your working copy. In a large project there may be lots of
experimental branches, and lots of copies of the whole project will take
up a lot of space, download time, etc.
On the other hand, if you just check out one branch at a time (by
working one level deeper in the hierarchy), you only need to have one
copy of the project on your disk at once. That's a better way to work.
And if you work that way, then creating a tag is simply a cheap copy
of the current version of the trunk.
I think it's useful to designate one branch as special, and you might as
well call that one the "trunk". It's also important to distinguish
between tags and active branches. You want to do it by naming revision
numbers, but then you'll have the problem of recording exactly which of
the many branches that existed at that point you meant. I think it's
better to be explicit about the scope of the tag, by making a snapshot
of everything you want to preserve.
>
> 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.
Right, that's normal behaviour. Testing would be done on a branch.
> Even worse, they will try to commit to tags as well. Thats one of the reasons
> why I think tags-as-copies are inconvenient.
Why would they do that? In my experience, it just doesn't happen (and
the repositories I work with don't use hooks to enforce the no-commit
rule, they just use the naming convention).
I suppose if you have the whole repository checked out, then you'll have
a copy of every tagged version of your project on disk, and you could
get lost and commit from the wrong place. But again: don't do that.
Check out the branch(es) you want to work on, and no more. Only check
out tags when you need to look at some detail of them.
Duncan Murdoch
>
>> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Feb 25 22:58:14 2006