Tagging Files to an Existing Tag/Branch

[Chris Clonch <cc...@gmail.com>]

First some background.  I am using subversion to version control UNIX 
configs and have established a development "branch" (/repo/dev/..) and a 
production "branch" (/repo/prod/..) as previously described here [1] and 
similar to here [2].  The idea is administrators will commit to 
/repo/dev (a la trunk).  Conceptually, once the files have been tested, 
they are tagged as production.  This cycle repeatedly occurs so that 
/repo/prod ends up being full of files and directories from various 
revisions that is never directly committed to.  And this is where my 
problem lies.  What is the best way to "tag" files at a specific 
revision in the development "branch" so that are in the production 
"branch"?  Ideally I'd like the solution to be fairly transparent to the 
admins as they are not accustomed to revision control systems.  If it 
helps, most are using Windows as their desktop OS and access the 
repository via the TortiseSVN Windows client.

My first thought was to treat /repo/prod as a subversion branch/tag, and 
copy the individual files in /repo/dev/<sub-path(s)/<file> at specific 
revisions to /repo/prod/<sub-path(s)>/<file>.  The cheap copy is perfect 
as these duplicate files wouldn't take up any more space.  And this is 
pretty easy to understand and do in Tortise.  However, Tortise complains 
it already existing if I try to tag a new file to an existing directory 
in /repo/prod.  On the command line, svn allows me to tag the new file 
but on subsequent tags of the same fime svn gives a failure opening 
message which I presume is due to the file existing.

So is there a subversion method to accomplish what I am looking to do? 
What are other possibilities/options?  I didn't really see an acceptable 
resolution in the previous posts I gave links to.  They also seemed to 
be pretty dated so I was curious if the newer subversion releases 
presented any newer solutions.  Please excuse me if this has been asked 
a thousand times before, but my brain is hurting from all the googling.

Thanks!
-Chris

[1] http://subversion.tigris.org/servlets/ReadMsg?listName=users&msgNo=16762

[2]
http://subversion.tigris.org/servlets/ReadMsg?listName=users&msgNo=17773

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Tagging Files to an Existing Tag/Branch

[Chris Clonch <cc...@gmail.com>]

Benjamin Smith-Mannschott wrote:
> I'm sure someone will chime in with a more practical suggestion, but...
> 
> [when I say 'trunk' I'm implying the existance of 'branches' and 'tags' 
> next to any such trunk.]
> 
> You've got multiple artifacts under a single trunk which have differing 
> release cycles, i.e. diverse versions.  I've found it useful to keep 
> under a single trunk only those files that are *always* tagged, 
> branched, released, *together*. ...

The only problem with that is everything would be its own trunk as 
(most) everything in the repository is independent of each other.  I'm 
fine with having a single trunk that contains differing release cycles 
given this is not being used for source code (other than simple shell 
and perl scripts).  However, I'm sure this leads to other problems down 
the road.  And it looks like my tagging issue is one of them...

  > ... In this case that would put each file into its own 'trunk', 
which is
> similar to what you are suggesting here. This has practical problems, as 
> you've discovered.

To clarify, my repo has a structure similar to this:

dev/
- scripts/
   - monitors/
- config/
   - cfengine/
   - common/
   - unique/
     - <hostname>/
     - <os>/
     - .../
- documents/

So there are a multitude of configs, scripts, and such residing in their 
respective directories that are, for the most part, independent of each 
other.  As the scripts are modified and tested, I want to be able to 
"tag" them as production so that we can take immediate advantage of the 
changes.  The structure is in no way set in stone, so long as it makes 
since and gains buy-in from the admins.

> The solution to the problem you're observing is to *remove* the file 
> you're trying to replace before you replace it.  But going this route 
> will also likely complicate the deployment of the 'prod' versions, since 
> I doubt you need your config files spread across lots of little trunks 
> when they are actually in use.

The need to first remove the existing file might be the answer.  While 
this requires multiple steps on the admins part, I'm sure they can live 
with it.

Regarding the lots-o-little trunks, I decided on using cfengine to push 
the files out so that the repo can have a layout that is beneficial (and 
makes sense) for subversion and cfengine can handle merging the files 
into their final resting place on each system.  Think of it as the 
administrative equivalent to separation of data and presentation. :)

> Well, let's see. On the one hand, it looks like you're using your 'prod' 
> branch, as a sort of staging area for your deployment.  You're probably 
> just updating an existing working copy of this branch and away-you-go.

Yes, the prod branch is our way of saying the config/script/etc has been 
QA'd and is "stable".

> But, you've still go the problem of a plethora of files in your 'dev' 
> branch which are not developed in lock-step.
> 
> I would stop thinking of 'prod' as a branch, and just consider it a 
> deployment staging area.  When a script or config file in 'dev' becomes 
> ready for production, just copy it to 'prod', taking care to remove the 
> old version beforehand.

I assume this would be a subversion remove and not an OS one...  I'm 
thinking this is the way to go.  In fact quickly trying it with Tortoise 
is pretty easy to grasp.  1) Perform a subversion remove on the prod 
file to remove it from my working copy.  2) Then, do a subversion copy 
of the dev file to prod in my working copy.  3) Results in a single commit.

> If you're ever curious to see which files in 'dev' have not yet been put 
> into 'prod', you can always use svn diff --summarize or the equivalent 
> TortoiseSVN function.

An added bonus I hadn't though of.  Although a quick test though shows 
that I'm going to have to read up on interpreting the columns as it 
relates to diff'ing two directories.

> Note, I'm not "tagging" the files in 'dev' as they become finished 
> explicitly. The fact that they have been moved to 'prod' and thus have 
> identical last-changed-revision and content in both 'dev' and 'prod' is 
> enough to document that they are done.
> 
> hth
> ben

Thanks Ben, your info has been helpful!

-Chris

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Tagging Files to an Existing Tag/Branch

[Benjamin Smith-Mannschott <bs...@gmail.com>]

On Aug 4, 2008, at 22:29, Chris Clonch wrote:

> First some background.  I am using subversion to version control  
> UNIX configs and have established a development "branch" (/repo/ 
> dev/..) and a production "branch" (/repo/prod/..) as previously  
> described here [1] and similar to here [2].  The idea is  
> administrators will commit to /repo/dev (a la trunk).  Conceptually,  
> once the files have been tested, they are tagged as production.   
> This cycle repeatedly occurs so that /repo/prod ends up being full  
> of files and directories from various revisions that is never  
> directly committed to.  And this is where my problem lies.  What is  
> the best way to "tag" files at a specific revision in the  
> development "branch" so that are in the production "branch"?   
> Ideally I'd like the solution to be fairly transparent to the admins  
> as they are not accustomed to revision control systems.  If it  
> helps, most are using Windows as their desktop OS and access the  
> repository via the TortiseSVN Windows client.
>

I'm sure someone will chime in with a more practical suggestion, but...

[when I say 'trunk' I'm implying the existance of 'branches' and  
'tags' next to any such trunk.]

You've got multiple artifacts under a single trunk which have  
differing release cycles, i.e. diverse versions.  I've found it useful  
to keep under a single trunk only those files that are *always*  
tagged, branched, released, *together*. ...

> My first thought was to treat /repo/prod as a subversion branch/tag,  
> and copy the individual files in /repo/dev/<sub-path(s)/<file> at  
> specific revisions to /repo/prod/<sub-path(s)>/<file>.  The cheap  
> copy is perfect as these duplicate files wouldn't take up any more  
> space.  And this is pretty easy to understand and do in Tortise.   
> However, Tortise complains it already existing if I try to tag a new  
> file to an existing directory in /repo/prod.  On the command line,  
> svn allows me to tag the new file but on subsequent tags of the same  
> fime svn gives a failure opening message which I presume is due to  
> the file existing.

... In this case that would put each file into its own 'trunk', which  
is similar to what you are suggesting here. This has practical  
problems, as you've discovered.

The solution to the problem you're observing is to *remove* the file  
you're trying to replace before you replace it.  But going this route  
will also likely complicate the deployment of the 'prod' versions,  
since I doubt you need your config files spread across lots of little  
trunks when they are actually in use.

> So is there a subversion method to accomplish what I am looking to  
> do? What are other possibilities/options?  I didn't really see an  
> acceptable resolution in the previous posts I gave links to.  They  
> also seemed to be pretty dated so I was curious if the newer  
> subversion releases presented any newer solutions.  Please excuse me  
> if this has been asked a thousand times before, but my brain is  
> hurting from all the googling.
>

Well, let's see. On the one hand, it looks like you're using your  
'prod' branch, as a sort of staging area for your deployment.  You're  
probably just updating an existing working copy of this branch and  
away-you-go.

But, you've still go the problem of a plethora of files in your 'dev'  
branch which are not developed in lock-step.

I would stop thinking of 'prod' as a branch, and just consider it a  
deployment staging area.  When a script or config file in 'dev'  
becomes ready for production, just copy it to 'prod', taking care to  
remove the old version beforehand.

If you're ever curious to see which files in 'dev' have not yet been  
put into 'prod', you can always use svn diff --summarize or the  
equivalent TortoiseSVN function.

Note, I'm not "tagging" the files in 'dev' as they become finished  
explicitly. The fact that they have been moved to 'prod' and thus have  
identical last-changed-revision and content in both 'dev' and 'prod'  
is enough to document that they are done.

hth
ben

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org