Hi Jeff et al,
These are myt 1st houghts about the Live,Staging,Devel layout.
Actually Jeff's email tgurned out to be just an excuse to discuss
something else I thought worth opening up.
First of all I understand Jeff's need, for example we have a web
content authoring system set up with physical dirs and boxes
with exactly those categories (staging is even called the same...)
I think the main issue is one of separation. It is nice/good to have
development work, which is often 'incomplete' when checked in,
separated from work which is say Beta, and that too separated
from release quality code/data.
I'll summarise what I think are the key requirements leading
to your layout. I've been toying with similar ideas.
Requirements:
* Separate dev, test, and release so that no pollution occurs.
* Permit intermediate developer/test checkins whilst nominally
maintaining the reference (trunk) version as monotonically
increasing in what I'll arbitrarily call quality.
'Issues':
* Trunk, Branches,Tags provide mechanism not policy.
There are many ways of managing development deltas.
Two that I'd like to concentrate on are:
A) Main line development commits with tags to (older) good versions
B) Development in branches with merges to mainline when passable.
A) Main line (trunk) developer commits
----------------------------------------------------
This means developers all checkin to the trunk. Branches don't really
get used for development work in this scenario.
A known good version of the trunk must be tagged so that a stable
version
is always ready for checkout by another developer (or worse still a
manager :-))
Pros:
* Conceptually simple
* Works for 1-2 developers on a small project
* Next person to checkout gets bleeding edge by default
(ie code divergence is not a problem, broken bones may be.. :-))
Cons:
* Main line will at some point contain good and broken code intermixed
on its timeline.
* Must remember (or automate) tagging of most recent known good
versions
B) Development done in branches
-----------------------------------------------
Here the mainline head (always a "good" copy) is checked out into a
branch
development is done in the branch. The developer can freely checkin
broken copies each night to save the dreaded:
tar cvf mondaynite.good.final2.tar project
(Hands up everyone who is pretending they've never done that!)
Anyhow once the developer has finished, and has a supposedly improved
version they then merge it into the trunk (maybe after a little
testing..yes?)
Pros:
* Better tracking of changes (a new branch should be created for
each logical change)
* Mainline is potentially much less polluted as merging can be
controlled
Cons:
* Conceptually a little harder.
* Requires more developer rigour or, lets be realistic, wrapper code
The possibility of using two mainlines also exists, where one mainline
is the official release (and patches) and the second mainline is the
alpha
development tree. However I would suggest at least conceptually that
it is just as simple to have one mainline and a tag/branch for a
release
version. I think it reasonable to say that in most cases there is one
active
line and the others are mostly patches to released versions. Therefore
a single trunk for major development and branches for maintenance
works well in all the cases I've had to deal with.
I suggest that for any non-trivial project B) is preferable, and it is
non-trivial
cases that are the most interesting and in most need of good version
control.
I'll deal with B) from now on.
The point about one logical change per branch has many implications.
Note that there is no reason why one couldn't just checkout a branch
and
use it for all time, merging as one goes along to keep it and the
trunk in sync.
I think is is needlessly complex (refer repeated merges, keeping track
of branch
deltas since last merge etc)
Instead I would suggest that (and I'm not claiming this to be
original) a branch
is created for each change (or set of related changes).
Indeed when a bug tracking system is in use we have a very convenient
branch naming scheme - the bug/issue#.
So to fix issue 1234 we create branches/branch-1234
[ Aside:
For those encumbered with management who delight in interfering with
developers and changing the bug tracking system every time a new
sales droid comes along - or worse those who have several incompatible
CRMs
out there (If you don't understand - believe me ignorance is bliss on
this one)
you might like to prefix the 1234 with an bug/CRM/issue system acronym
-eg
branches/branch-ABC1234 or just branches/ABC1234
because the change of getting a globally unique
number out of each system is ...)
]
Now all our changes for issue 1234 get committed to branch-ABC1234
so we have a nice history of the fixes for issue 1234.
It also means we can work on several distinct issues at once in our
home dirs
simply by having the working dirs named after the branch/issue.
[I know there are cases with humungous projects where it is impractical
to check out multiple copies, but in these cases I'd suggest one isn't
changing
EVERY file, so maybe construct a branch of a subtree or a composite of
those
bits which will be changed. More thought/discussion required here.]
When it comes time to integrate one or more changes into the main line
these can be managed by a person or a script. if you have the people
good.
It all adds to the process workflow paradigm without unduly impinging
on
developer efficiency. Even automated integration phases are good,
because
branches which don't build can be easily rejected without affecting
others.
Ok well this is getting to be a bit long so I'll come back quickly to
Jeff's
suggestion of Dev/Test/Release.
I think that whilst at first is make a clean distinction between the
areas,
it adds somewhat to the migration management tasks and one ends
up with 3 tag areas, 3 branch areas etc which _might_ be harder to
manager down the track.
The need for separation is there however, and I think it can be
more simply and scalably achieved by going for a naming scheme
within the single tag and branch directories - ie inverting the
problem.
So we'd end up with:
project/tags/RELEASE-x.y.z
project/tags/DEV-issue# # note may not need DEV tags
project/tags/TEST-x.y.z
and the same for branches:
project/branches/RELEASE-x.y.z # note prob don't need RELEASE branches
project/branches/DEV-issue#
project/branches/TEST-x.y.z # note prob. don't need TEST branches
where x.y.z is a suitable version number etc
In practice I think only 3 of the above 6 cases would actually be
needed.
Releases should only be TAGS not branches (one could argue about
patches here)
DEV are really branches not tags.
Admittedly with SVN ithis is a moot point, but it is important to get
one's conceptual
model correct. I'd suggest "releases" are points in time not deltas so
they are tags
never branches.
If desirable one could make the RELEASE etc into a subdir rather than
just a prefix
ie project/tags/RELEASE/....
A benefit of this general solution rather than /Live/Trunk etc
is that we can easily add extra tag schemes as required (eg
RELEASE-BETA
or PILOT etc when the world becomes more complex)
By creating a template naming convention for tags and branches
(which still reamains flexible) we create a helpful policy based on a
powerful
underlying mechanism (SVN)
A final thought. Using well defined tag/branch names makes automation
(my pet topic and something I'm working on for SVN) so much simpler.
Thanks for reading this far :-)
regards
kim
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Apr 22 19:17:45 2003