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_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-08-04 23:58:55 CEST