On Sat, Jul 01, 2006 at 07:18:24AM -0400, Nico Kadel-Garcia wrote:
> 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.
As Nico noted, using cfengine doesn't really help with the original
problem. I am deploying Config
(http://www.cs.umb.edu/~rouilj/#OtherThings) rather than cfengine and
migrating from a cvs based to a svn based repository and have exactly
the same problems that Les and the OP has.
It derives from the relationships between the files. In a normal
development environment you work toward the case where all the files
in the tree will work together as a whole application. That isn't the
case for my, or the original poster's use. We have small groups of
files (5 files/group in my case on average) that are related, but we
have dozens of groups. Web sites or related pages (say a new entry in
a style sheet and the three pages that use this new entry) in the OP
and config file sets in my case.
Many of the files in the trunk that are pushed for testing whether by
cfengine or Config may not be ready for production use. Using cvs, the
code review step from test (trunk development) to production was
finalized by moving the 'production' tag to the subset of the files in
trunk with the reviewed and tested functionality.
E.G. I make a change to the host configuration database, a Makefile
and 2 template files to deploy a VPN gateway at a new site. I only
need these 4 files to be pushed into production and no other files.
In CVS I move my floating tag "production" to the reviewed revs of
these files and I am done. In SVN I need to create a new (production)
branch that is identical to the current (production) branch except for
these 4 files. These 4 files and only these 4 files must come from a
revision on the trunk.
If the system is used by multiple people with various tasks in
progress, because of the non-coupling of the source files, it is very
unlikely that there will ever be a point in time where the trunk is
usable as a new production branch. So we have to have floating tags or
the ability to check out hundreds of files specifying exactly which
revision of each file is to be put into the branch.
I have been experimenting with the following algorithm for floating
branch/tag in svn. I don't know yet if it will work though:
1 create a production branch using the standard copy operation.
(svn copy URL-TRUNK URL-FLOATING_BRANCH) aka
(svn copy URL-TRUNK URL-FB)
2 for each file you want to move to the floating branch from the head
of the development trunk
a remove the file in the floating branch
(svn delete URL-FB/path/to/file)
b copy the file from production tree to floating branch
(svn copy -r <rev> URL-TRUNK/path/to/file URL-FB/path/to/file)
the -r <rev> in 2b can be omitted if you know that there is no newer
copy of the file on the trunk. I was also thinking of using revision
properties (svn propset floating:branch "<rev> URL-TRUNK/path/to/file")
to record the revision and path of the copy to the production tree.
One thing that is a pain is the renaming of files/moving of
directories. It has to be done twice once in the trunk and once in the
floating branch tree. With CVS the tags worked along the version axis
of the repository rather then in the filesystem space. So the
production tags followed the renames/reorgs of the CVS tree for the
most part. That is not the case using the system above.
--
-- rouilj
John Rouillard
System Administrator
Renesys Corporation
603-643-9300 x 111
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Jul 3 17:05:26 2006