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