Sylvain Viart wrote:
> I rewrite my proposed svn use:
>
> 1. developers use trunk, and commit what ever they need.
Excellent.
> 2. when ready they update part of their changes on the deployment wc
> (somewhat: cd /deploy ; svn up -r myrev or HEAD somefiles)
Bad. It means that the deployment server (what I call test server) is not at a
single rev, and hence the totality of this checkout cannot be easily replicated
to some other server. It also means that the deployment server is basically
only able to be messed with by one person at a time (since you don't want to
have multiple people updating multiple, possibly interrelated, files).
> 3. if it works as expected, some test are performed on the new code
> and the wc is validated for production
> 1. the wc is copied into a tags and deployed on production
> server based on that new tag (probably a switch or an export
> or something equivalent (rsync +filter))
> 2. the deployment wc is freed but keep its states (here I block
> with this topic)
> 3. END
Tags good. Switch good. Export bad. The reason is that you now have no idea
what is on the production server, since you have severed it from the version
control system. If you use switch, a simple 'svn info' shows you exactly what
tag the production server is currently at. The overriding goal of an VCS is to
*not* lose information. The only (IMNSHO) good reason to use export is when
building a tarball for distribution (which doesn't sound like what you are
talking about anyways). I'll deal with item 3.2 in the next comment.
> 4. if it doesn't work, the deployment wc may be altered by the
> developer testing its code, to match preproduction environment
> requirement for example.
> * if the changes are slim they are commited in the trunk, they
> we go at step 3
> * if the changes seems too big, the developer must free the
> deployment wc and go back to the DEV aborting its deployment.
Very bad. If you make changes to the deployment WC, small or large, you are
just asking for trouble, because you then have to merge that back to the trunk.
What if, while Developer A is making his changes work on the deployment
machine, Developer B commits her changes to trunk which cause a conflict. Now,
when Dev A is done and happy, he tries to merge the dev branch back to trunk and
hits conflicts that he didn't cause. It is a form of action at a distance and
it is very hard to deal with. If you treat the repository as the One True Code,
then each developer is only responsible for dealing with the conflicts caused by
committing their local changes.
Additionally, it is all too easy to make changes to the deployment server and
then forget to commit them back. And the next person to update the deployment
server then has to deal with them (and may have no clue who made those changes
or even what they mean). Because you are assuming that the developers can
update an single file to a given rev, it may be weeks before anyone does a full
update and discovers massive breakage because the WC as a hole is inconsistent.
And forgotten updates can fester for weeks or months if you never perform a
full update at all.
> 5. the deployment is aborted the deployment wc must be reverted to
> its previous stable states. somewhat a saved tag, but should be in
> the trunk?? same as 3.2, I block here.
Again, if the deployment server is simply a checkout of trunk (or branch) it is
trivial to revert changes back to the last stable state, but only if you haven't
made any local (to the deployment server) changes.
I don't know what your workflow is like. You haven't said how many developers
you have working on the project, how often you have destabalizing changes
committed, how often two developers will be working on the same section of code,
how long it typically takes a developer to write a "change", or really what kind
of project you are talking about. I can't make more detailed recommendations
without much more information.
But I can tell you what works for us, based on our workflow of a number of
basically independent websites in a single repository, with only occasional
developer overlap:
- All commits are made to trunk except for large reorganization/rewrites which
happen in a branch;
- The test server is always up to date with trunk (except when a large branch is
in progress, where it is always up to date with that branch);
- The test site is allowed to break and the person who broke it is typically
responsible for fixing it;
- If this is an executable application as opposed to a web site, it is a very
good thing to have a buildbot (or as many as you have targeted platforms) that
is constantly building the latest rev and running your test suite (this is now
called "continuous integration");
- The production server is always pointing at the most recent tag;
- No changes are allowed to tags (if a problem is detected, fix it quick and
create a new tag).
HTH
John
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Oct 2 12:39:03 2007