On Thu, Sep 1, 2011 at 12:25 PM, Brendan Flanagan
<brendan.flanagan_at_wegobeyond.co.uk> wrote:
> All,
>
> One of our customers is implementing subversion and TSVN and they have
> decided on a repository structure that is slightly different than "the norm"
> and I wanted to check if it had any "flaws"?
>
> They support and develop enhancements to a purchased product (they don't
> have the source for the purchased product, only their enhancements).
>
> They want "trunk" to reflect the current Production Release of their
> enhancements only. They intend creating a branch called "Development" that
> the small number of developers will use day to day - i.e. they will add new
> enhancements, change existing code etc.
Things like this make David sad...
Managers and consultants love this idea because it sounds so good.
Then, the idea is you keep replacing "development" with what is in
"trunk" every time you start new development. After all, you know that
trunk is what's in production!
There are many things wrong with the idea. One is that you're
constantly copying and tagging and you're going to get lost. Someone
is going to forget to copy the tag to trunk. Then, when a bug is found
in production, you'll be basing it on the wrong release.
Tagging is skipped because it's a production bug and you're in a
hurry. Plus, your release procedure is inconsistent, Sometimes,
you're releasing from trunk, sometimes from a release branch,
sometimes from development. Sometimes tags are made, sometimes they're
not.
Also notice what happens:
1). Development is done on "development"
2). A release is done and is tagged by copying "development to the
"tags" directory.
3). That tag is copied to "trunk" because that's what's in production.
4). Production is copied back to "development" when new work needs to be done.
Notice you're copying from development to tags to trunk and back to
development. Now, you are working on development and find a bug in
production. You fix it in "trunk" because that's what is in
production. However, copying production to development won't work.
You'll lose development work. However, the circular motion of all that
copying is going to cause all sorts of merge issues.
And, what about file history? The development history of
development/foo.c isn't straight forward. What you see is a copy from
trunk which was copied from tags which was copied from an older
version of the development branch that was replaced when you copied
trunk to development.
There's a reason why we do development in trunk, copy trunk to a
release branch, and then tag from the branch. It's easy to track
what's going on, and if you need to merge a bugfix from a release into
development, it's easy to do. The copying is only done in a single
direction. The history is clear, and the release procedure is
repeatable. Plus, you'll get in the habit of tagging anything that
goes into production.
Is it that they just want to see what's in production? Why not create
a special PRODUCTION tag?
$ svn cp %REPOS%/module/tags/%TAG% %REPOS%/module/tags/PRODUCTION
This way, development is still straight forward, and you can even view
the history of what's in production via:
$ svn log %REPOS%/module/tags/PRODUCTION"
You'll see what release is in production, and the complete history of
all releases, when they were placed in production, etc.
--
David Weintraub
qazwart_at_gmail.com
Received on 2011-09-01 21:00:42 CEST