Title: RE: [oic] RE: SVN-Related Practices and Customs
Dennis,
> I noticed the preference for a top-level branching (from trunk/ to
> branches/ and /tags) in the SVN documentation, although the examples
> explored most fully involve multiple projects, even grouped projects,
> with the individual projects having their own trunk, branches, and tags
> sub-folders.
Yes, that's another approach. Apache does this with their projects.
On the other hand, the SVN project maintains their code, tools and website
in a single trunk-branches-tags hierarchy.
> I looked around a little more in the free O'Reilly Version Control with
> Subversion: for Subversion 1.5.
For those who aren't familiar with it: http://svnbook.red-bean.com
And on Windows you have this wonderful tool http://tortoisesvn.tigris.org
Of course there are lots of other tools as well on other platforms.
> For example, if I had some path like
>
> SpecAnal/ - 1.1/ - 17/ - 17.2/ - stuff/ - foo
> |
> - wip
> and I want to "branch" (actually "clone" at the same revisions) the
> stuff folder, I can't do it into a subfolder of stuff. So I would have
> to make the branch into a different child of 17.2/ assuming that I
> wanted some sort of proximity. That's confusing, because there may
> be other siblings of 17.2 and the naming gets wacky. The alternative
> is to use something like
>
> SpecAnal/ - 1.1/ - 17/ - 17.2/ - trunk/ - stuff/ - foo
> | |
> | - wip
> - tags/ - 17.2v01 / - stuff/ - foo
> |
> - wip
Mm, I'm not an SVN guru, but I don't think you should do that, IMHO it would
be better to do it like this for non-trivial amounts of work
SpecAnal/ - trunk/ - 1.1/ - 17/ - stuff/ - foo
|
- bar
branches/ - working_on_17/ - 1.1/ - 17/ - stuff/ - foo
|
- bar
In SVN this is a lazy operation, so creating a branch hardly takes up any
space (probably you can also "copy" a single subdirectory to the branch, but
IIRC that makes merging slightly more difficult. Haven't used it for a while
so if anyone can clarify this... :-)
Once you're happy with the branch, you could then merge it back to the trunk.
This way the trunk stays "stable". For trivial changes, one might directly
change it in the trunk, otherwise we'll end up with branches for every typo
or small improvement.
And after a while, when having a decent number of changes, we could create
a tag called "review_01" or whatever.
> One really doesn't want trunks under trunks.
No, actually the whole point is to only have one trunk/tags/branches structure,
be it at the root or as a (first or one of the first) sublevel of your
project
So perhaps it would be wise to organise it like this:
Scenarios_TestDocs / - trunk/
- branches/
- tags/
SpecAnalysis_ODF11/ - trunk/ - 1/ - 1.1/ ....
- branches/
- tags/
SpecAnalysis_ODF12/ - trunk/
- branches/
- tags/
FooBarStuff/...
I'm assuming here that many test scenarios / documents can be reused by
simply setting a custom property "odf:version" on the file, while it will
be more confusing to do the same thing for spec analysis due to change in
chapter numbering and so on. Feel free to comment on this.
Even if we currently don't do branches. It used to be the case that, when
doing a move / rename, you'd had to flip an option in your tool to see the
whole history log. No big deal actually, but if we can avoid it...
Best regards,
Bart
