Trying to emulate moving tags under CVS and update working copy to that tag.

Hello all:

I am the author of Config. A mechanism for maintaining systems (sort
of a precursor to cfengine, puppet, bcfg2 etc). When it was originally
created CVS was the only available SCM that would work.

Subversion sort of works to replace CVS (modulo not restoring
permissions and ownership/groups when updating a working copy) however
there is one important mode that I just can't seem to figure out how
to make work without causing quite a bit of extra work compared to
CVS.

A few sites that deploy config maintain a "production" tree of tested
config files that are automatically pushed to all systems. The
standard cycle is:

  check out working copy of file to change
  change it and check into CVS
  use Config on a test (working copy maintained by Config) config area
      to test the changes to a subset of systems
  get change promoted to production
  push to entire world

This "production" tree is identified by a tag "prod" on the files that
should be pulled when a cvs update occurs. When a file is ready to be
moved to production, a user (other than the person who generated the
file to be tagged) simply moves the tag to the new revision of the
file which is ready for production. (Note using this mechanism, it's
possible to have files from different branches in the production
tree.) Then the Config system's production working copy just pulls the
files with the current "prod" tag from the repository to push to all
the systems.

I am trying to produce a similar mechanism for svn. Ideally I need to
find a simple way to do it that:

   permits verification of the change against the work tree before
       checking into the production tree

   works in the repository only without a working copy

   allows preservation of local changes in the production tree

   provides a link that shows which revision of the working
      copy of each file is present in the production tree.

As an example: svnrepo/work/users/sudoers needs to be promoted to
svnrepo/production/users/sudoers. Initially the production branch is
created via "svn copy .../svnrepo/work .../svnrepo/production".
now what I want to do is:

   svn copy
     .../svnrepo/work/users/sudoers@544
     .../svnrepo/production/users/sudoers

but this generates an error:

  svn: Path 'production/users/sudoers' already exists

I could also "svn merge .../svnrepo/production/users/sudoers
.../svnrepo/work/users/sudoers@544" into a currently checked out
production tree. (This does revert any local production branch changes
but there is only one area of the repository where this will be an
issue). However there is no way to do the equivalent to:

  svn diff .../svnrepo/work/users/sudoers@HEAD db

(i.e. mix a URL and a local working copy) to see what the differences
are between my reference file (which is not the version on my branch)
and the file I am going to check in if I have to apply changes local
to the production branch.

Once that is done I think I can:

   svn propset config:revision 544 .../svnrepo/work/users/sudoers

to record the current 'production file version' -> 'working file
revision' mapping. (If I need to support multiple branches, I can use
a property like config:url and specify a full svn URL to another
branch).

I have seen email chains on tagging:

   http://svn.haxx.se/dev/archive-2004-04/0131.shtml

that seem to echo my dilemma. Having tags/branches in the file system
namespace rather than along other axes seems to make the problem I am
facing a fundamental limitation.

Is the above the best I can do? Does anybody have any tips for
handling these issues?

-- 
				-- 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