Hi,
you can easily do the complete development on the "release-branch" if your
company works on one BIG product. The company I work for has several
products which share a large amount of code, organized in libraries. The
different products have different release cycles.
Before we were branching for releases the development took a little bit
place like the following scenario:
Product A was about to released, so the complete code of the product A
(including the libraries) was frozen and only bug fixes were allowed.
Developers of Product B always had to make sure that their changes would not
affect product A.
So, nowadays we're developing our products in the trunk, as mainline of
development. Releases that need feature freeze must be branched.
If we would only develop in release branches for different product, there
would be a lot of merge operations necessary between different release
branches for the libraries (aka. shared code). With a trunk any changes made
to a release branch can be easily merged back.
That's why we need a trunk.
On 1/11/07, B. Smith-Mannschott <benpsm@gmail.com> wrote:
>
> 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
>
>
Received on Fri Jan 12 23:51:08 2007