[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Updating a live website with a post-commit hook script

From: Nico Kadel-Garcia <nkadel_at_comcast.net>
Date: 2006-07-01 13:18:24 CEST

Bob Proulx wrote:
> Les Mikesell wrote:
>> Bob Proulx wrote:
>>> Tags in CVS are often used like cheap branches. What you describe
>>> looks like a subversion branch.
>>
>> Yes - I want a branch that represents exactly the testing workspace
>> but I only want it to appear to anyone else when testing is complete.
>
> Changes in the subversion repository are atomic. But updates to a
> working copy are not and will take time to checkout. Is atomicity
> during a checkout important? If so then you would need to check out
> on the side and do a rename probably through a symlink to quickly cut
> over to the new copy. But achieving perfect atomicity can be
> difficult. In fact I don't know how to do it.

Hmm. The CVS/Subverson/etc. repository is one thing, but there are often
configuration files that need local tweaking. May I suggest that what Les
really wants is CFengine, which he can then put under Subversion to ahve
source control? It has the control structures for handling slightly
different servers in slightly different ways built right in, and supports
dynamic local reconfiguration in a way that's difficult and needs to be
written from scratch to live directly in Subversion.

> This is where we diverge. In CVS a tag can move. Or you can choose
> never to move it.
>
> A tag such as RELEASE-4.2.1 I would expect never to move from the
> files it identifies. But a tag such as LATEST I would expect to float
> to the top and always track the HEAD. They are both tags. But the
> purpose they are being put to is completely different purposes.

Yeah. This behavior is not enforced by default! The tags/branches/trunk of
Subversion are social conventions, not programming ones. They can be
enforced by things like svnperms.conf and svnperms.py, fortunately, and I
really, really encourage setting them up to prevent editing of tags once
created. Then you create branches from that, as needed, and work from there
and allow them to be modified, or merge changes to the trunk and encourage
people to use that.

> The process model I was proposing was an unstable trunk where all
> development happens on the main trunk. Then a stable branch where
> known good snapshots of the trunk are captured with a tag.

Tags need not come from the trunk. Tags can come from branches. The one
booby trap is that, once you've done that, you can never get the damn branch
out of the repository without flushing the tags, as well. The lack of an
"obliterate" or similar operation for Subversion is a problem when you're
trying to reduce the amount of debris in the repository, especially when
some smart-aleck accidentally spews things all over your trunk or the top
directory of your repository. That's one reason I like svnperms.conf and
svnperms.py so much: You can protect your trunk, tags, and root of your
directory from having people spew all over them and make an amazing mess to
clean up.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Jul 1 13:19:16 2006

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.