I'm experimenting with my own idea on layout, and I'm thinking:
main (rather than trunk)
releases (equivalent to branches, but with a specific use)
builds (equivalent to tags, because we tag each build)
branches (for doing something that isn't a release)
personal (for people do create a personal branch as a "sandbox"
to test something in)
One reason for this is that I'll use hooks to ensure:
1. no one can commit to "builds" - they are frozen points in time
2. no one can delete releases, main, or builds
branches and personal can be deleted. The only difference
is that "branches" is for some activity that is team wide,
while "personal" is for individual sandbox activity, and
expected to often delete branches after sandbox work is done.
-----Original Message-----
From: B. Smith-Mannschott [mailto:benpsm@gmail.com]
Sent: Thursday, January 11, 2007 10:39 AM
To: Subversion Users
Subject: What's a "trunk" good for? (apart from eating peanuts)
Hi!
I'm muddling along trying to develop part of a little internal
subversion crash course at my place of work. Currently, I'm trying
to teach the concepts of trunk, branch and tag. The more I think
about it, the more I'm convinced that 'trunk' is conceptual baggage
we've schlepped in from the world of CVS. Trunk is just a special
case of branch. The "everything is a directory" reality of subversion
just makes this even more obvious.
I guess my conceptual problem is two-fold:
(1) it's meaning: why should it get special treatment?
(2) it's appellation: why should we call it "trunk"?
**
Conventionally, I think "trunk" used for the 'main line of
development'. At least that's what we've been doing. But what does
that really mean?
We do all of our development work in the various "trunk" of our
repository here, but really, it might as well just be a branch called
"release-1", since that's what we're working toward and we all know
that. When we're ready to stabilize "release-1", we could branch it
by copying it to "release-2" where bleeding-edge development would
continue while stabilization fixes are made to "release-1".
In this scenario it's seems like it's an eternally shambling branch
forever doomed to blearily stumble from one release to the next,
never quite sure which it belongs to. In a word, it's messy.
What's so special about "trunk"? In retrospect, wouldn't it be
clearer just to work "trunkless"?
**
In another very different case, I have a small internal web site
(publishing a collection of XML schemas), where 'trunk' is the
*stable* (the website is a published version of the content. I use
short-lived feature branches to make changes and then merge these
back into trunk. But in this case there is only ever *one* true
version of the site so there's no need to keep parallel branches of
development open. (Though that may change, and then what?)
But even here, where "trunk" is useful it's clear that it's just
another branch. Heck, I could even give it a marginally more sensible
name, like "branches/official-version" or whatever.
**
In a third case, we're managing the publication of a collection of
documentation for our system. Here we've left the trunk/branch/tag
naming convention behind entirely, also in part because it's used by
non-technical users.
"Work" holds the version currently under active modification. That
is, it's the staging area for the next publication.
"Final" contains copies of Work. These are essentially release
branches. They are made in order to have a stable collection of
source documents (MS Word) from which to produce what's actually
delivered (PDF).
"Published" contains copies of "Final" branches recording what was
included in any given published version. These correspond to tags.
**
In a fourth case, I've created a small repository for a decidedly non-
technical user whose previous version control consisted of making
renamed copies of the files she maintained *before* she modified
them. She was blessedly consistent in that the renaming always
consisted of adding an ISO date to the original name of the file.
Out of this motley collection, I created a repository consisting of a
single active branch (trunk) and a plethora of tags. But, I didn't
call them that. Instead I localized them to the native language of
my workplace:
aktuell/ ("current", i.e. the "trunk")
archiv/ ("archive" -- a place to keep old copies of things for
reference)
20050912-i-made-this-up
20061031-some-text-about-what-i-did-here
readme/ (user documentation)
She uses tortoiseSVN and I've shown her how to make changes to
"aktuell" and commit them and then how to copy-and-rename "Aktuell"
to a new subdirectory in "archiv" using tortoiseSVN's hand-but-
unintuitive right-mouse-button-drag maneuver.
It seems to work for her, but it sure isn't very conventional.
**
I guess my difficulty is that I'm trying to give guidance. But I know
that it's all just *convention* so the most honest guidance I could
give is: "actually you can do what you want, but **you've got to
understand what you're doing!**". Which begs the question: do I
truly understand what *I'm* doing?
I'd be curious as to how you are using (or not using) "trunk" and in
particular what *meaning* you've given it.
Thanks,
Ben
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Jan 11 22:48:25 2007