Sylvain Viart wrote:
> It's for deployment purpose.
>
> I've a dedicated trunk wc for deployment, and for now it's more that
> often in mixed version states.
You are really making this much more difficult than it needs to be. A tag is
merely a copy that represents a collection of files at specific revisions; there
is *no* requirement that all files must be as of the same revision. For that
matter, you can make a tag based on an existing mixed-revision working copy ala
svn cp . http://url/path
Your method of tweaking the rev of many files in your "trunk_wc" means that
there is *no* control over those files. In other words, if the server holding
"trunk_wc" were to fail, there would be no easy way to recreate that set of
files. This kind of scheme is completely ignoring the strengths of version
control. You might as well be copying the files up manually every time using
'svn cat'. You are literally keeping an unversioned collection of files on
disk; each files itself is versioned, but the *collection* itself is completely
random and not tracked.
If I am understanding your scheme, then I can suggest an alternate one. How
about I give you the ability to keep any given WC pointing at the most current
tag [matching a regex], with as much of the tag history maintained as you like
(so you can roll back to any point in time)? All your developers have to do is
to create a tag with a predefined (by you) name, and a post-commit script will
keep that WC in sync automatically. This is particularly good for web site
developers because it means that there is no need to ever update the production
server directly - the post-commit script does all of the work for you.
I wrote SVN::Notify::Mirror for this precise purpose. One of the most powerful
capabilities is to match a commit path based on a regular expression and switch
a WC to this new path. You shouldn't fear switch, it is very efficient. It
only updates the files that change between rev A and rev B, so if you have large
WC's, it will only change those specific files.
Here is my proposed development schema:
1) All normal development happens on trunk (though you can just as easily use
branches)
2) Any testing server you have always tracks trunk using a post-commit script
3) The production server always tracks the latest tag that matches some regex,
say RELEASE-YYYYMMDDSEQ, also using the same post-commit script.
Here is your postcommit file (using SVN::Notify::Config):
#!/usr/bin/perl -MSVN::Notify::Config=$0
--- #YAML:1.0
'':
PATH: "/usr/bin:/usr/local/bin"
'project/trunk':
handler: Mirror
minimal: 1
to: "/path/to/www/htdocs"
'project/tags':
handler: Mirror::SSH
tag-regex: "^RELEASE-"
to: "/path/to/remote/www/htdocs"
ssh-host: "remote_host"
ssh-user: "remote_user"
ssh-identity: "/home/user/.ssh/id_rsa"
That file constitutes both the data and the post-commit script in one. It keeps
the local directory "/path/to/www/htdocs" in sync with the trunk at all times.
It keeps the remote diretory "/path/to/remote/www/htdocs" in sync with the
latest tag that matches the string "^RELEASE-" (full Perl regex capabilities).
Additionally, the remote server is updated using a specific ssh user/key.
Does this seem like it does what you want?
HTH
John
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Sep 26 13:17:03 2007