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_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-08-05 19:47:45 CEST