You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Graham Anderson <gr...@siren.cc> on 2006/06/29 00:58:41 UTC
Updating a live website with a post-commit hook script
Hi
1) Is there an example script and tutorial on how to update a live
web site with a post-commit hook script ?
2) Does this comply with a 'best practices' use for subversion ? At
this point, I am a bit too green to evaluate if this is ok.
I am very new to subversion so any help is appreciated.
From: http://subversion.tigris.org/faq.html
> I'm managing a website in my repository. How can I make the live
> site automatically update after every commit?
>
> This is done all the time, and is easily accomplished by adding a
> post-commit hook script to your repository. Read about hook scripts
> in Chapter 5 of the book. The basic idea is to make the "live site"
> just an ordinary working copy, and then have your post-commit hook
> script run 'svn update' on it.
many thanks
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Updating a live website with a post-commit hook script
Posted by Nico Kadel-Garcia <nk...@comcast.net>.
Les Mikesell wrote:
> On Fri, 2006-06-30 at 20:05, Nico Kadel-Garcia wrote:
>>>
>>> Wow. That is truly ugly. If an admin can't control PATH being used
>>> by the hook scripts then there are problems well beyond security.
>>> Because I can't believe that someone would feel there is a need to
>>> purge PATH by design. That just feels so wrong to me.
>>
>> Hmm. Since many subversion tools operate as different users at
>> different times, depending on whether they're run through Apache,
>> svnserver, or the local filesystem, it's not safe to assume that any
>> or all of these people have sane PATH settings. Better safe than
>> sorry, I think.
>
> So what's safe? Unless you are the only admin on the box,
> second-guessing where binaries live doesn't sound safe to
> me. Sourcing /etc/profile if it exists might work in
> a lot of places.
As opposed to second-guessing where they might have been stuffed? The hook
scripts are pretty simple, and easy to keep control over. A clueless admin
is likely to do all sorts of oddness, or worse yet another user using the
file-based access with odd PATH setups that aren't consistent and don't work
well for perl, bash, csh, or whatever the hook script is written in due to
inconsistently set user profiles.
Been there, have the scars.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Updating a live website with a post-commit hook script
Posted by Les Mikesell <le...@gmail.com>.
On Fri, 2006-06-30 at 20:05, Nico Kadel-Garcia wrote:
> >
> > Wow. That is truly ugly. If an admin can't control PATH being used
> > by the hook scripts then there are problems well beyond security.
> > Because I can't believe that someone would feel there is a need to
> > purge PATH by design. That just feels so wrong to me.
>
> Hmm. Since many subversion tools operate as different users at different
> times, depending on whether they're run through Apache, svnserver, or the
> local filesystem, it's not safe to assume that any or all of these people
> have sane PATH settings. Better safe than sorry, I think.
So what's safe? Unless you are the only admin on the box,
second-guessing where binaries live doesn't sound safe to
me. Sourcing /etc/profile if it exists might work in
a lot of places.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Updating a live website with a post-commit hook script
Posted by Nico Kadel-Garcia <nk...@comcast.net>.
Bob Proulx wrote:
> Ryan Schmidt wrote:
>> Bob Proulx wrote:
>>> /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
>>> That looks like the same PATH that is in effect for apache. I am
>>> sure it is being inherited, just as desired.
>>
>> According to the documentation, the path should be empty:
>>
>> http://svnbook.red-bean.com/nightly/en/svn.reposadmin.create.html#svn.reposadmin.create.hooks
>>
>>> For security reasons, the Subversion repository executes hook
>>> scripts with an empty environment—that is, no environment variables
>>> are set at all, not even $PATH or %PATH%. Because of this, a lot of
>>> administrators are baffled when their hook script runs fine by
>>> hand, but doesn't work when run by Subversion. Be sure to
>>> explicitly set environment variables in your hook and/or use
>>> absolute paths to programs.
>
> Wow. That is truly ugly. If an admin can't control PATH being used
> by the hook scripts then there are problems well beyond security.
> Because I can't believe that someone would feel there is a need to
> purge PATH by design. That just feels so wrong to me.
Hmm. Since many subversion tools operate as different users at different
times, depending on whether they're run through Apache, svnserver, or the
local filesystem, it's not safe to assume that any or all of these people
have sane PATH settings. Better safe than sorry, I think.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Updating a live website with a post-commit hook script
Posted by Bob Proulx <bo...@proulx.com>.
Ryan Schmidt wrote:
> Bob Proulx wrote:
> > /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
> >That looks like the same PATH that is in effect for apache. I am sure
> >it is being inherited, just as desired.
>
> According to the documentation, the path should be empty:
>
> http://svnbook.red-bean.com/nightly/en/svn.reposadmin.create.html#svn.reposadmin.create.hooks
>
> > For security reasons, the Subversion repository executes hook
> > scripts with an empty environment—that is, no environment variables
> > are set at all, not even $PATH or %PATH%. Because of this, a lot of
> > administrators are baffled when their hook script runs fine by
> > hand, but doesn't work when run by Subversion. Be sure to
> > explicitly set environment variables in your hook and/or use
> > absolute paths to programs.
Wow. That is truly ugly. If an admin can't control PATH being used
by the hook scripts then there are problems well beyond security.
Because I can't believe that someone would feel there is a need to
purge PATH by design. That just feels so wrong to me.
> There have been many questions on this list over the past year where
> people wonder why their hook scripts don't work, and when they're
> told to use absolute paths, they respond saying that worked.
I would set PATH at the top of my script to something reasonable.
PATH=${PATH-/usr/local/bin:/usr/bin:/bin}
And then still avoid hard coded paths.
> I've tested this before, and again just now, by creating a new
> repository, creating a post-commit hook in it to log all the
> environment variables to a file, checking it out via the file:///
> protocol, and committing a change, and most environment variables,
> including PATH, are not set, just like the docs say.
Based upon your observation I just tested this again and what I see is
that my exported environment includes only PWD. But my shell
variables not exported includes PATH, SHELL and TERM. Because PATH
exists for the current shell, even though it is not exported, it
functions for commands in that shell. If I were to launch a child
shell script this would not show up there because it is not an
exported variable.
I believe this is a bash feature. Try this:
env -i bash
echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
That is why this is working for me. Because bash is not finding any
PATH in the environment and therefore falling back to a compiled in
default. It sets it for its own use but does not export it.
Hmm... This tells me that I should export PATH in my hook scripts.
Although it does not really solve the problem.
export PATH
In a normal shell PATH is one of the special ones that is always
exported. Just changing it is enough. But with the env purge the
special status of it has been changed and while it is available for me
it is no longer exported.
> But I've also seen messages recently from Windows users saying the
> path is set, though it was set to an unexpected value.
The MS-Windows environment always frustrates me to no end and I avoid
it whenever possible. So hearing reports of problems there I usually
leave to the MS crowd to fix. But this data would indicate that it is
shell specific what compiled in PATH it would fallback to. I tested
ksh on HP-UX and it did not fall back to any built in PATH.
> Just now I created a test repository and served it via Apache, and
> was surprised to see that all the environment variables I have set in
> my shell were inherited by the hook script.
Exported? Or no? (The difference between 'env' and 'set'.)
> So either the documentation needs to be updated to explain when the
> environment will be empty and when it won't be, or the Subversion
> code needs to be changed to match the documented behavior.
Or better yet both updated to allow PATH. :-)
> I tested with Subversion 1.3.2 and Apache 2.2.2 on Mac OS X 10.4.6
> PPC G4.
Debian GNU/Linux stable/backports for me.
Bob
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Updating a live website with a post-commit hook script
Posted by Ryan Schmidt <su...@ryandesign.com>.
Bob Proulx wrote:
> Ryan Schmidt wrote:
>
>> Bob Proulx wrote:
>>
>>> Lots of hard coded paths! If /usr/bin is not in path then there
>>> is a
>>> problem. Hard coded paths to programs have always come back to bite
>>> me. I recommend avoiding them.
>>
>> Um, since /usr/bin/svnlook is explicitly specified, /usr/bin does not
>> need to be within the path. This is in fact the whole point, because
>> in Subversion hooks, the path is not set, so you must use absolute
>> paths or it won't work.
>
> Uhm, they work for me. PATH *is* set for me when the hook scripts are
> run. You can test this for yourself by save the $PATH in effect when
> the hook script is run. In my case when run from my web server the
> following PATH is set at the time the hooks are run:
>
> /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
>
> That looks like the same PATH that is in effect for apache. I am sure
> it is being inherited, just as desired.
Interesting.
According to the documentation, the path should be empty:
http://svnbook.red-bean.com/nightly/en/
svn.reposadmin.create.html#svn.reposadmin.create.hooks
> For security reasons, the Subversion repository executes hook
> scripts with an empty environment—that is, no environment variables
> are set at all, not even $PATH or %PATH%. Because of this, a lot of
> administrators are baffled when their hook script runs fine by
> hand, but doesn't work when run by Subversion. Be sure to
> explicitly set environment variables in your hook and/or use
> absolute paths to programs.
There have been many questions on this list over the past year where
people wonder why their hook scripts don't work, and when they're
told to use absolute paths, they respond saying that worked.
I've tested this before, and again just now, by creating a new
repository, creating a post-commit hook in it to log all the
environment variables to a file, checking it out via the file:///
protocol, and committing a change, and most environment variables,
including PATH, are not set, just like the docs say.
But I've also seen messages recently from Windows users saying the
path is set, though it was set to an unexpected value.
Just now I created a test repository and served it via Apache, and
was surprised to see that all the environment variables I have set in
my shell were inherited by the hook script.
So either the documentation needs to be updated to explain when the
environment will be empty and when it won't be, or the Subversion
code needs to be changed to match the documented behavior.
I tested with Subversion 1.3.2 and Apache 2.2.2 on Mac OS X 10.4.6
PPC G4.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Updating a live website with a post-commit hook script
Posted by Bob Proulx <bo...@proulx.com>.
Ryan Schmidt wrote:
> Bob Proulx wrote:
> >Lots of hard coded paths! If /usr/bin is not in path then there is a
> >problem. Hard coded paths to programs have always come back to bite
> >me. I recommend avoiding them.
>
> Um, since /usr/bin/svnlook is explicitly specified, /usr/bin does not
> need to be within the path. This is in fact the whole point, because
> in Subversion hooks, the path is not set, so you must use absolute
> paths or it won't work.
Uhm, they work for me. PATH *is* set for me when the hook scripts are
run. You can test this for yourself by save the $PATH in effect when
the hook script is run. In my case when run from my web server the
following PATH is set at the time the hooks are run:
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
That looks like the same PATH that is in effect for apache. I am sure
it is being inherited, just as desired.
> It might be better to define variables (or constants, depending on
> language) for the programs used, right at the top of the script, so
> that if you need to change the path, they're all in one place.
I still disagree with that type of implementation. It is very fragile
to operating system differents. One problem that it often leads to is
that it can become difficult to impossible to test scripts without
actually installing them. Or sometimes situations arise where people
think they are testing their changes off on the side but they are
actually running the installed copy. In both cases the problem is
that with hard coded paths it might be impossible to test without
actually installing them.
> The actual problem with the script above was that the svnlook command
> is not passed the $REV argument.
Very good for that analysis. I did not look at that script that
closely. I just liked the concept of only updating the files that
changed instead of everything.
Bob
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Updating a live website with a post-commit hook script
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Jun 30, 2006, at 08:55, Bob Proulx wrote:
>> open (P, "/usr/bin/svnlook changed $REPOS|");
>> system("/usr/bin/svn up $working_dir/Website/$file");
>
> Lots of hard coded paths! If /usr/bin is not in path then there is a
> problem. Hard coded paths to programs have always come back to bite
> me. I recommend avoiding them.\
Um, since /usr/bin/svnlook is explicitly specified, /usr/bin does not
need to be within the path. This is in fact the whole point, because
in Subversion hooks, the path is not set, so you must use absolute
paths or it won't work. It might be better to define variables (or
constants, depending on language) for the programs used, right at the
top of the script, so that if you need to change the path, they're
all in one place.
The actual problem with the script above was that the svnlook command
is not passed the $REV argument.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Updating a live website with a post-commit hook script
Posted by Bob Proulx <bo...@proulx.com>.
I. E. Smith-Heisters wrote:
> You can also get a bit more fancy about it. If you run "svn up" on the
> root of your working directory, it has to churn through the whole
> directory, which can take quite some time depending on the size of
> your codebase. Instead, you can use post-commit's arguments to
> specifically update files, which, IME, cuts the update time to about
> 1/10th of the time. Here's an example in Perl:
Very nice! Thanks for sharing that example. It definitely is more
efficient than my brute force example However I think as an example
the brute force one is more clear. Learn one and then expand to the
other? :-)
> open (P, "/usr/bin/svnlook changed $REPOS|");
> system("/usr/bin/svn up $working_dir/Website/$file");
Lots of hard coded paths! If /usr/bin is not in path then there is a
problem. Hard coded paths to programs have always come back to bite
me. I recommend avoiding them.
Thanks again for the script!
Bob
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Updating a live website with a post-commit hook script
Posted by "I. E. Smith-Heisters" <pu...@0x09.com>.
You can also get a bit more fancy about it. If you run "svn up" on the
root of your working directory, it has to churn through the whole
directory, which can take quite some time depending on the size of
your codebase. Instead, you can use post-commit's arguments to
specifically update files, which, IME, cuts the update time to about
1/10th of the time. Here's an example in Perl:
#!/usr/bin/perl
use warnings;
use strict;
my ($REPOS, $REV) = @ARGV;
my $working_dir = '/var/www';
open (P, "/usr/bin/svnlook changed $REPOS|");
while (<P>) {
$_ =~ /^.\s+(.*$)/;
my $file = $1;
$file =~ s/website\/trunk//;
system("/usr/bin/svn up $working_dir/Website/$file");
}
So, that would take a repo path of /website/trunk/file and update the
filesystem file /var/www/Website/file. I actually haven't tested the
code above, it's part of a larger script, but something like that
should work.
-Ian
On 6/29/06, Bob Proulx <bo...@proulx.com> wrote:
> Graham Anderson wrote:
> > 1) Is there an example script and tutorial on how to update a live
> > web site with a post-commit hook script ?
>
> I don't know if official examples exist but the implementation is
> really only a few lines.
>
> > 2) Does this comply with a 'best practices' use for subversion ? At
> > this point, I am a bit too green to evaluate if this is ok.
>
> Yes. This is a best practice. It is recommended in the FAQ as you
> noted in your message.
>
> http://subversion.tigris.org/faq.html#website-auto-update
>
> Let's assume a subversion repository at /srv/svn/www and a web
> document root at /srv/www. You could have a post-commit hook at
> /srv/svn/www/hooks/post-commit with this content:
>
> #!/bin/sh
> cd /srv/www || exit 1
> svn update --quiet
> exit 0
>
> A very simple process. Change directory to the live web working copy
> and update it.
>
> This process will run as the web process uid. On my machine that
> means the www-data user. On other machines it will be different. The
> live working copy needs to be owned by the www-data user or at least
> be writable by it so that the web server uid can update it.
>
> Of course you don't need to use the https:// protocol to update. You
> could use the svn+ssh:// protocol. But if you are updating a web page
> then we can assume that you have a web server and so have https://
> available. This avoids a permission problem.
>
> If you use svn+ssh:// then the post-commit is run as the committing
> uid which will be different for everyone. For a web server document
> root keeping it writable by everyone is probably not what you want to
> do. This is where the little C program wrapper described in the FAQ
> becomes useful. Set up a set-uid program to switch to a pseudo user
> to update the web document root. Make it writable only by that pseudo
> user.
>
> Hope that helps!
> Bob
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: subversion and mysql synchronizing
Posted by Thomas Harold <tg...@tgharold.com>.
Graham Anderson wrote:
> I would like to use subversion to synchronize local, development, and
> live mysql databases.
>
> These databases are serving a web site that is already under
> subversion's control.
>
> As subversion is working wonderfully on my local,live, and development
> web sites, how can I include mysql into the mix?
> Is this accomplished with a hook script?
I suspect the answer is going to be that SVN isn't suited for this.
Keeping track of the SQL queries, or copies of dump files, or the
exported data that is going to be moved from development to production
would probably work.
OTOH, we throw data sets around using MDBs stored in SVN (used to use
VSS/SOS) during testing. But those data sets were then manually loaded
into a production SQL server via a manual step. We'd also store the
data sets back into MDB at the end of the project and place them in our
VCS for posterity.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
subversion and mysql synchronizing
Posted by Graham Anderson <gr...@siren.cc>.
I would like to use subversion to synchronize local, development, and
live mysql databases.
These databases are serving a web site that is already under
subversion's control.
As subversion is working wonderfully on my local,live, and
development web sites, how can I include mysql into the mix?
Is this accomplished with a hook script?
Is this possible or desired? Is anyone doing this?
many thanks
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Updating a live website with a post-commit hook script
Posted by Graham Anderson <gr...@siren.cc>.
thanks :)
that helps a bunch
g
On Jun 28, 2006, at 11:54 PM, Bob Proulx wrote:
> Graham Anderson wrote:
>> 1) Is there an example script and tutorial on how to update a live
>> web site with a post-commit hook script ?
>
> I don't know if official examples exist but the implementation is
> really only a few lines.
>
>> 2) Does this comply with a 'best practices' use for subversion ? At
>> this point, I am a bit too green to evaluate if this is ok.
>
> Yes. This is a best practice. It is recommended in the FAQ as you
> noted in your message.
>
> http://subversion.tigris.org/faq.html#website-auto-update
>
> Let's assume a subversion repository at /srv/svn/www and a web
> document root at /srv/www. You could have a post-commit hook at
> /srv/svn/www/hooks/post-commit with this content:
>
> #!/bin/sh
> cd /srv/www || exit 1
> svn update --quiet
> exit 0
>
> A very simple process. Change directory to the live web working copy
> and update it.
>
> This process will run as the web process uid. On my machine that
> means the www-data user. On other machines it will be different. The
> live working copy needs to be owned by the www-data user or at least
> be writable by it so that the web server uid can update it.
>
> Of course you don't need to use the https:// protocol to update. You
> could use the svn+ssh:// protocol. But if you are updating a web page
> then we can assume that you have a web server and so have https://
> available. This avoids a permission problem.
>
> If you use svn+ssh:// then the post-commit is run as the committing
> uid which will be different for everyone. For a web server document
> root keeping it writable by everyone is probably not what you want to
> do. This is where the little C program wrapper described in the FAQ
> becomes useful. Set up a set-uid program to switch to a pseudo user
> to update the web document root. Make it writable only by that pseudo
> user.
>
> Hope that helps!
> Bob
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Updating a live website with a post-commit hook script
Posted by "I. E. Smith-Heisters" <pu...@0x09.com>.
If it doesn't by default, it's not difficult to hack the Apache
response chain and make it do whatever you want. Still, it's probably
easier just to have a working copy. Alternatively, you could also just
have a PHP script that fetches files from the repo and does any
necessary processing.
On 6/29/06, Rainer Sokoll <r....@intershop.de> wrote:
> Greg Thomas wrote:
> > On Thu, 29 Jun 2006 15:23:51 +0200, Rainer Sokoll
> > <r....@intershop.de> wrote:
>
> >>What if svn:mime-type is set to application/x-httpd-php?
> >
> > The MIME type of a file only affects how the client displays it. PHP
> > etc. code is processed server side.
>
> [The discussion goes slightly off topic, but I cannot stop myself ;-)]
>
> I disagree.
> To my best knowledge:
> If you do not have somewhere in your apache config:
>
> "AddType application/x-httpd-php .php" or
> "application/x-httpd-php php" in mime.types
>
> then apache will deliver the contents of your php file as text/plain.
> If you have one of the statements above, apache will pass the php file
> to mod_php (if DSO is supported) and then deliver whatever the php
> script returns.
> So my question is: Does mod_svn give back its results to apache for
> further processing (for example mod_php) or not?
>
> Rainer
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Updating a live website with a post-commit hook script
Posted by Bob Proulx <bo...@proulx.com>.
Les Mikesell wrote:
> Slight variation on the question: how would you make the site stay
> at a tagged version so untested changes could be committed, then
> tested and tagged when verified?
Make the tag using a specific version.
svn copy -r42123 $URL/trunk $URL/tags/GOOD-2006-06-30
By specifying the -r42123 you will not get the top of trunk but
instead will get exactly that version of the trunk. This is
regardless of whether people are continuing to check things into the
trunk or not.
Bob
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Updating a live website with a post-commit hook script
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Jun 29, 2006, at 18:54, Les Mikesell wrote:
> On Thu, 2006-06-29 at 11:53 -0400, jason wrote:
>> You've asked the question and gotten several responses saying that
>> you
>> either can't do what you want, or that what you want to do can be
>> done much
>> easier by simply using post-commit hooks to update a working copy
>> that can
>> be served by Apache. Yet you keep arguing.
>>
>> If you think all of those responses are wrong, wouldn't it be
>> easier to go
>> and try it out and if those responses were proved incorrect
>> (unlikely) to
>> provide this new-found knowledge back to the mailing list?
>
> Slight variation on the question: how would you make the site stay
> at a tagged version so untested changes could be committed, then
> tested and tagged when verified? I used to do this with CVS by
> rtagging the tested copy to float a known tag to that version,
> followed
> by an update to the working version, always using the same tag. That
> way it didn't matter if additional untested changes had been
> committed.
> The script also floated a couple of previous-release tags backwards
> so you could always back out to earlier versions without having to
> track any release numbers or tags.
I don't know CVS, but two solutions spring to mind:
1. Have a trunk and a branch. The web site points to a working copy
of the branch. Do active development on trunk. Merge those changes
that are tested and should appear on the site into the branch. In the
post-commit hook, update the working copy of the branch when a commit
happens on the branch.
2. If you want a more hands-on approach, you could make a tag of the
trunk or a branch or whatever version you want to release, and then
"svn switch" the working copy to that tag. We manage our sites this
way. We have a nice script which does the switching for us when we
tell it to. (We don't want our production sites updating themselves
any old time; we want to be there and push the button explicitly.)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Updating a live website with a post-commit hook script
Posted by Tony Morris <tm...@tmorris.net>.
I use a continuous build integration system such as Luntbuild.
Maybe that can solve the problem?
--
Tony Morris
http://tmorris.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Updating a live website with a post-commit hook script
Posted by Bob Proulx <bo...@proulx.com>.
Les Mikesell wrote:
> Blair Zajac wrote:
> > I would look at using svnmerge.py to merge revisions from a trunk,
> > to a QA branch to a production branch. svnmerge.py will manage
> > all the metadata for you to ensure that only revisions that
> > haven't been merged over will be merged. You can also cherry pick
> > revisions to merge.
> ...
> I'm just trying to make this flow easy enough that no one will ever
> try to bypass it or forget to merge (most) QA changes back to the
> trunk.
Personally I find svnmerge good for merging from the trunk into a
branch. But I have never gotten it to work for merging changes back
from the branch into the trunk. But I did not pursue the problem to
root cause.
Bob
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Updating a live website with a post-commit hook script
Posted by Les Mikesell <le...@gmail.com>.
On Fri, 2006-06-30 at 13:11 -0700, Blair Zajac wrote:
> I would look at using svnmerge.py to merge revisions from a trunk, to a QA
> branch to a production branch. svnmerge.py will manage all the metadata for you
> to ensure that only revisions that haven't been merged over will be merged. You
> can also cherry pick revisions to merge.
>
> You can find svnmerge.py in
>
> http://svn.collab.net/repos/svn/trunk/contrib/client-side/
Thanks - I think separate QA and production branches are probably
the cleanest approach and it might even make the production head
jump atomically to the right versions of everything where floating
a CVS tag had a small timing window where things were inconsistent.
But, if there were changes in QA, most of the time these should
go back to the trunk as well - and I don't really care about keeping
a history of the QA branch after it is merged to production.
I'm just trying to make this flow easy enough that no one will ever
try to bypass it or forget to merge (most) QA changes back to the
trunk.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Updating a live website with a post-commit hook script
Posted by Blair Zajac <bl...@orcaware.com>.
Les Mikesell wrote:
> On Fri, 2006-06-30 at 01:24 -0600, Bob Proulx wrote:
>
>>>> Tags in Subversion are not like tags in CVS. In CVS, you "apply a
> tag
>>>> to a file." A tag is a property of a file. (Or so I've heard. I
> never
>>>> used CVS.)
>>> It is, but the main reason you apply them is to group all the files
>>> you want at once. That is, if you have updated your working copy at
>>> some earlier time and your snapshot passes the testing, you can use
>>> the rtag command to apply a specified tag to the repository copy of
>>> all the files at the versions you have even if the repository now
> has
>>> new untested updates. A subsequent checkout/update of that tag will
>>> get exactly the same versions as the workspace where the tag was
>>> applied.
>> Tags in CVS are often used like cheap branches. What you describe
>> looks like a subversion branch.
>
> Yes - I want a branch that represents exactly the testing workspace
> but I only want it to appear to anyone else when testing is complete.
>
>> However in CVS tags can be moved.
>> And tag movement is an unversioned operation. No versioning of tags
>> exists in CVS. In subversion however all operations are versioned.
>
> The point of the tags is that someone has blessed this particular
> group of versioned files, which in CVS are versioned individually.
>
>> This means that the CVS operation of moving tags does not map directly
>> to a subversion operation. This is by design because in CVS it is
>> possible to completely mess up a repository by moving tags and have no
>> history of the action.
>
> Tags don't actually have any effect on the file versioning and moving
> them doesn't affect any history. It only affects which file versions
> are identified by that tag.
>
>> Avoiding that and making all operations
>> versioned in subversion was a design goal.
>
> I think this is leading to using 2 branches - one for the test snapshot,
> then one for the release after someone blesses it.
>
>>>> But you could certainly
>>>> have a tag called "ready for beta" and simply delete it and
> recreate
>>>> it when you want to update it.
>>> That sounds reasonable. Is there a way to rename existing tags? In
>>> the CVS scheme I would use rtag to change the RELEASE tag to
>>> RELEASE-1, etc. for a few downrev versions, then add a new RELEASE.
>> This is just semantics but it sounds more like a branch than a tag to
>> me. Branches can change and mutate over time. But tags imply
>> something that does not change. In CVS it was just a quirk of the
>> implementation that that tags were also used as cheap branches.
>
> I think of it a different way. In CVS, files are versioned separately
> and tags are the way you identify a set of file versions so you
> can operate on the same set repeatably. The files are expected to
> continue to change and the point of the tag is to identify the
> state of a snapshot of the set. Normally you would just keep adding
> new tags with increasing version numbers - and you can do that too if
> you want but then everyone has to track what is the latest tagged
> version. For this purpose I just want to identify the latest file
> versions that have been tested together for current production and the
> one to use to back it out and floating a known tag seems easier than
> tracking variable ones.
>
>>>> Why is merging not an option?
>>> The idea is to make the system foolproof so you can have different
>>> groups coding, testing, and installing and the only way code gets
>>> to production is by the testers marking it as ready in the
> repository.
>>> Developers should never have to stop modifying the trunk and the
>>> installers shouldn't have to keep track of anything to get the
>>> latest known-working version.
>> I think what you just said is that people should not be merging the
>> data. In the situation you describe I can agree with that.
>>
>>> Since subversion naturally groups files in a commit, maybe the
>>> tagging operation isn't needed to identify a snapshot but you
>>> still need a way to mark the points that have been tested.
>> I think because subversion versions directory trees that you can
>> automate making perfect merges to branches behind the scenes. People
>> would never have to deal with it but a script could easily do so. Of
>> course you have to get it going but then...
>>
>> THEN=$(date +%F-%T)
>> svn copy $URL/trunk $URL/tags/release-$THEN
>> ...work.test.work...
>> ...test.work.test...GOOD.VERSION!...
>
> The catch is that the top line needs to overlap the bottom
> part independently. That is, the tester takes the current
> repository head as his starting point. Meanwhile developers
> may commit changes that go into the next cycle. If the
> tester finds a problem with one file, with CVS he could
> fix it and commit that file or ask the developer to do it,
> then update that file into his workspace before the rtag
> operation. If you can't do individual file changes in
> subversion, I think that means the testing copy has to be
> on a branch so as not to interfere with other concurrent
> commits on the main trunk that we don't want to pick up
> yet. But we probably do want the fix the tester adds put
> into the trunk. Does that become a separate operation
> or is there a way to finalize this such that the testing
> workspace can be blessed into a release tag or branch and
> any changes also go back into the trunk where other changes
> may have occurred by now?
I would look at using svnmerge.py to merge revisions from a trunk, to a QA
branch to a production branch. svnmerge.py will manage all the metadata for you
to ensure that only revisions that haven't been merged over will be merged. You
can also cherry pick revisions to merge.
You can find svnmerge.py in
http://svn.collab.net/repos/svn/trunk/contrib/client-side/
Regards,
Blair
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Updating a live website with a post-commit hook script
Posted by John Rouillard <ro...@renesys.com>.
On Sat, Jul 01, 2006 at 07:18:24AM -0400, Nico Kadel-Garcia wrote:
> Bob Proulx wrote:
> >Les Mikesell wrote:
> >>Bob Proulx wrote:
> >>>Tags in CVS are often used like cheap branches. What you describe
> >>>looks like a subversion branch.
> >>
> >>Yes - I want a branch that represents exactly the testing workspace
> >>but I only want it to appear to anyone else when testing is complete.
> >
> >Changes in the subversion repository are atomic. But updates to a
> >working copy are not and will take time to checkout. Is atomicity
> >during a checkout important? If so then you would need to check out
> >on the side and do a rename probably through a symlink to quickly cut
> >over to the new copy. But achieving perfect atomicity can be
> >difficult. In fact I don't know how to do it.
>
> Hmm. The CVS/Subverson/etc. repository is one thing, but there are often
> configuration files that need local tweaking. May I suggest that what Les
> really wants is CFengine, which he can then put under Subversion to ahve
> source control? It has the control structures for handling slightly
> different servers in slightly different ways built right in, and supports
> dynamic local reconfiguration in a way that's difficult and needs to be
> written from scratch to live directly in Subversion.
As Nico noted, using cfengine doesn't really help with the original
problem. I am deploying Config
(http://www.cs.umb.edu/~rouilj/#OtherThings) rather than cfengine and
migrating from a cvs based to a svn based repository and have exactly
the same problems that Les and the OP has.
It derives from the relationships between the files. In a normal
development environment you work toward the case where all the files
in the tree will work together as a whole application. That isn't the
case for my, or the original poster's use. We have small groups of
files (5 files/group in my case on average) that are related, but we
have dozens of groups. Web sites or related pages (say a new entry in
a style sheet and the three pages that use this new entry) in the OP
and config file sets in my case.
Many of the files in the trunk that are pushed for testing whether by
cfengine or Config may not be ready for production use. Using cvs, the
code review step from test (trunk development) to production was
finalized by moving the 'production' tag to the subset of the files in
trunk with the reviewed and tested functionality.
E.G. I make a change to the host configuration database, a Makefile
and 2 template files to deploy a VPN gateway at a new site. I only
need these 4 files to be pushed into production and no other files.
In CVS I move my floating tag "production" to the reviewed revs of
these files and I am done. In SVN I need to create a new (production)
branch that is identical to the current (production) branch except for
these 4 files. These 4 files and only these 4 files must come from a
revision on the trunk.
If the system is used by multiple people with various tasks in
progress, because of the non-coupling of the source files, it is very
unlikely that there will ever be a point in time where the trunk is
usable as a new production branch. So we have to have floating tags or
the ability to check out hundreds of files specifying exactly which
revision of each file is to be put into the branch.
I have been experimenting with the following algorithm for floating
branch/tag in svn. I don't know yet if it will work though:
1 create a production branch using the standard copy operation.
(svn copy URL-TRUNK URL-FLOATING_BRANCH) aka
(svn copy URL-TRUNK URL-FB)
2 for each file you want to move to the floating branch from the head
of the development trunk
a remove the file in the floating branch
(svn delete URL-FB/path/to/file)
b copy the file from production tree to floating branch
(svn copy -r <rev> URL-TRUNK/path/to/file URL-FB/path/to/file)
the -r <rev> in 2b can be omitted if you know that there is no newer
copy of the file on the trunk. I was also thinking of using revision
properties (svn propset floating:branch "<rev> URL-TRUNK/path/to/file")
to record the revision and path of the copy to the production tree.
One thing that is a pain is the renaming of files/moving of
directories. It has to be done twice once in the trunk and once in the
floating branch tree. With CVS the tags worked along the version axis
of the repository rather then in the filesystem space. So the
production tags followed the renames/reorgs of the CVS tree for the
most part. That is not the case using the system above.
--
-- 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
Re: Updating a live website with a post-commit hook script
Posted by Nico Kadel-Garcia <nk...@comcast.net>.
Bob Proulx wrote:
> Les Mikesell wrote:
>> Bob Proulx wrote:
>>> Tags in CVS are often used like cheap branches. What you describe
>>> looks like a subversion branch.
>>
>> Yes - I want a branch that represents exactly the testing workspace
>> but I only want it to appear to anyone else when testing is complete.
>
> Changes in the subversion repository are atomic. But updates to a
> working copy are not and will take time to checkout. Is atomicity
> during a checkout important? If so then you would need to check out
> on the side and do a rename probably through a symlink to quickly cut
> over to the new copy. But achieving perfect atomicity can be
> difficult. In fact I don't know how to do it.
Hmm. The CVS/Subverson/etc. repository is one thing, but there are often
configuration files that need local tweaking. May I suggest that what Les
really wants is CFengine, which he can then put under Subversion to ahve
source control? It has the control structures for handling slightly
different servers in slightly different ways built right in, and supports
dynamic local reconfiguration in a way that's difficult and needs to be
written from scratch to live directly in Subversion.
> This is where we diverge. In CVS a tag can move. Or you can choose
> never to move it.
>
> A tag such as RELEASE-4.2.1 I would expect never to move from the
> files it identifies. But a tag such as LATEST I would expect to float
> to the top and always track the HEAD. They are both tags. But the
> purpose they are being put to is completely different purposes.
Yeah. This behavior is not enforced by default! The tags/branches/trunk of
Subversion are social conventions, not programming ones. They can be
enforced by things like svnperms.conf and svnperms.py, fortunately, and I
really, really encourage setting them up to prevent editing of tags once
created. Then you create branches from that, as needed, and work from there
and allow them to be modified, or merge changes to the trunk and encourage
people to use that.
> The process model I was proposing was an unstable trunk where all
> development happens on the main trunk. Then a stable branch where
> known good snapshots of the trunk are captured with a tag.
Tags need not come from the trunk. Tags can come from branches. The one
booby trap is that, once you've done that, you can never get the damn branch
out of the repository without flushing the tags, as well. The lack of an
"obliterate" or similar operation for Subversion is a problem when you're
trying to reduce the amount of debris in the repository, especially when
some smart-aleck accidentally spews things all over your trunk or the top
directory of your repository. That's one reason I like svnperms.conf and
svnperms.py so much: You can protect your trunk, tags, and root of your
directory from having people spew all over them and make an amazing mess to
clean up.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Updating a live website with a post-commit hook script
Posted by Les Mikesell <le...@gmail.com>.
On Fri, 2006-06-30 at 20:52, Bob Proulx wrote:
> > > Tags in CVS are often used like cheap branches. What you describe
> > > looks like a subversion branch.
> >
> > Yes - I want a branch that represents exactly the testing workspace
> > but I only want it to appear to anyone else when testing is complete.
>
> Changes in the subversion repository are atomic. But updates to a
> working copy are not and will take time to checkout. Is atomicity
> during a checkout important?
No, I think that is basically hopeless when the changes need
to be propagated across a farm of servers anyway. The update
would happen to a staging server followed by running a script
that rsync's to the production servers.
> > Tags don't actually have any effect on the file versioning and moving
> > them doesn't affect any history. It only affects which file versions
> > are identified by that tag.
>
> Negative. We are talking past each other. Because tags in cvs do
> affect file versioning and moving them definitely changes history.
File versioning always happens in CVS independently from tags.
The tag is just a convenient name for a particular set of them.
You can always get any version of any file without the tag.
> > > > That sounds reasonable. Is there a way to rename existing tags? In
> > > > the CVS scheme I would use rtag to change the RELEASE tag to
> > > > RELEASE-1, etc. for a few downrev versions, then add a new RELEASE.
>
> If yesterday I cvs checkout -rRELEASE I get a set of files identified
> by the RELEASE tag. Then you bless the RELEASE tag either on new
> files or on later versions of files to identify a new contour with
> RELEASE, moving that floating tag to a new set of files. Then
> tomorrow I cvs checkout -rRELEASE and I will get a different set of
> files than I got yesterday.
>
> The tag RELEASE now identifies something different then it did before.
> Files identified by RELEASE have changed. And cvs does not record the
> history of the movement of tags and so looking at cvs log will not
> show me when the RELEASE tag was applied nor when it was moved to a
> new version. The two trees both checked out with RELEASE are
> different and I have no way to tell when this occurred nor even
> exactly what changes occurred.
RELEASE always identifies the set of files you applied it to,
which is exactly why you apply it. In my example, I always
floated 3 tags 'up' a position so I maintained my own
history of where prior tags had been (RELEASE-1 moves up
to RELEASE before RELEASE moves to the versions in the
testing workspace). I've never actually backed out a whole
release anyway but it is nice to know it would be possible.
Occasionally old versions of individual files are needed
but the file history is always there independently from
the tags.
> Using a floating tag like that is common in cvs. This is why I call
> it a "cheap branch". It is maintaining a branch-like behavior that
> file versions can change from moment to moment with different file
> revisions being identified by it. By my reasoning if you can get a
> different result at different times from the same command then it has
> branch-like behavior.
The testing workspace is sort-of a branch. Changes can happen
there and be committed back while the head of the repository
continues to change. Then the tag identifies the versions
as they exist in the workspace. However, with a set of fast
changing web sites you might push updates to production daily
or more often and rarely if ever back anything out, so the
history of groupings in the testing set isn't all that
useful.
> > I think this is leading to using 2 branches - one for the test snapshot,
> > then one for the release after someone blesses it.
>
> That seems perfectly workable. I think it requires more merging
> because you will need to merge changes from the trunk onto each
> branch. But that should still work fine.
Wouldn't you work in the test branch if changes are needed
and then merge to production from there?
> This is where we diverge. In CVS a tag can move. Or you can choose
> never to move it.
If you wanted an 'unchanging history' method in CVS, I suppose
you could script a way to get the list of files/versions as
they exist in the test workspace, then check out exactly that
list instead of using a tag as a reference to the set. That
would be repeatable at any future time.
> That is the *other* behavior of cvs tags. LATEST would move. But
> when LATEST moves the history of where it pointed to previously is
> lost. This is not supported by cvs. But svn uses directory trees for
> tags and versions tree operations.
I'm not particularly interested in the history of the testing
branch - I just need a workspace to gather the versions that
will go to production, perhaps with a few changes. Is it
possible to delete it, or is it cheap enough to ignore?
> > If the tester finds a problem with one file, with CVS he could fix
> > it and commit that file or ask the developer to do it, then update
> > that file into his workspace before the rtag operation.
>
> There are different ways to do that change. On a branch? On the main
> trunk and then merge back into the branch? On the main trunk and then
> just move the tag to the file on the main trunk? In that last case
> what if the main trunk has other incompatible changes already?
>
> Could you outline that part in a little more detail?
There are a couple of likely possibilities. One is a small change
that the tester would do himself which I'd expect to be done in the
testing branch, the other would involve notifying the developer who
committed the broken version that it needs to be fixed, which
would probably be done on the trunk and merged in. And there
will be the rare case where a quick fix needed to make this
snapshot work should not be on the trunk because you will do
it the right way there later.
> > If you can't do individual file changes in subversion,
>
> I don't quite agree with that statement.
OK, I'm certainly not an expert or I wouldn't be asking...
> > > NOW=$(date +%F-%T)
> > > svn copy -rGOODVERSION $URL/trunk $URL/tags/release-$NOW
> > > svn checkout $URL/branch/latest .
> >
> > I don't want anything else that has been committed to the trunk
> > at this point other than what the tester might have changed or
> > requested to have changed. Isn't this operation going to pick
> > up unrelated new work?
>
> No. Because I specified the -rGOODVERSION it will select specifically
> that revision of the trunk. Developers may have committed changes on
> top of that version but this will copy it based on the specified
> version. New commits will not be copied to the tag.
OK, but when we ask the developer to fix that one thing, how
do we get it into the trunk, the test branch, and the test
workspace without picking up other unrelated changes that
may now be on the trunk?
> The process model I was proposing was an unstable trunk where all
> development happens on the main trunk. Then a stable branch where
> known good snapshots of the trunk are captured with a tag.
>
> A disadvantage is that the main trunk must periodically work and
> become a good version so that it can be captured. Or it is an
> advantage. This is where different people will have different
> opinions.
I don't think it is right for this case. There will be times
where there will be work in progress on the trunk that should
not be in production but a change is needed from the snapshot
taken for the test step. We need a place where that change
can be made.
> I consider it an advantage. One of the premises of agile code
> development is that the project should be always kept in a releasable
> state.
I think that's impractical for our case. I want work-in-progress
to live in the repository so it is always backed up and people
are less likely to make conflicting changes. And sometimes
updates need to go to production before the whole trunk
is snapshot-ready.
> Therefore I consider this normal when working in an agile
> development environment. If the code is always releasable and always
> passing all tests then it is easy to periodically make a release from
> the main trunk. Or as in the case above pull changes from the main
> trunk into the release branch.
That would be a good approach for something more monolithic than
a set of web sites with lots of different parts updated by
different people.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Updating a live website with a post-commit hook script
Posted by Bob Proulx <bo...@proulx.com>.
Les Mikesell wrote:
> Bob Proulx wrote:
> > Tags in CVS are often used like cheap branches. What you describe
> > looks like a subversion branch.
>
> Yes - I want a branch that represents exactly the testing workspace
> but I only want it to appear to anyone else when testing is complete.
Changes in the subversion repository are atomic. But updates to a
working copy are not and will take time to checkout. Is atomicity
during a checkout important? If so then you would need to check out
on the side and do a rename probably through a symlink to quickly cut
over to the new copy. But achieving perfect atomicity can be
difficult. In fact I don't know how to do it.
> > However in CVS tags can be moved.
>
> The point of the tags is that someone has blessed this particular
> group of versioned files, which in CVS are versioned individually.
I think the key point is that in cvs you can move a tag creating a
"floating tag" behavior. In svn this is not supported. But
fortunately other ways are provided to handle this.
> > This means that the CVS operation of moving tags does not map directly
> > to a subversion operation.
>
> Tags don't actually have any effect on the file versioning and moving
> them doesn't affect any history. It only affects which file versions
> are identified by that tag.
Negative. We are talking past each other. Because tags in cvs do
affect file versioning and moving them definitely changes history.
> > > That sounds reasonable. Is there a way to rename existing tags? In
> > > the CVS scheme I would use rtag to change the RELEASE tag to
> > > RELEASE-1, etc. for a few downrev versions, then add a new RELEASE.
If yesterday I cvs checkout -rRELEASE I get a set of files identified
by the RELEASE tag. Then you bless the RELEASE tag either on new
files or on later versions of files to identify a new contour with
RELEASE, moving that floating tag to a new set of files. Then
tomorrow I cvs checkout -rRELEASE and I will get a different set of
files than I got yesterday.
The tag RELEASE now identifies something different then it did before.
Files identified by RELEASE have changed. And cvs does not record the
history of the movement of tags and so looking at cvs log will not
show me when the RELEASE tag was applied nor when it was moved to a
new version. The two trees both checked out with RELEASE are
different and I have no way to tell when this occurred nor even
exactly what changes occurred.
Using a floating tag like that is common in cvs. This is why I call
it a "cheap branch". It is maintaining a branch-like behavior that
file versions can change from moment to moment with different file
revisions being identified by it. By my reasoning if you can get a
different result at different times from the same command then it has
branch-like behavior.
> I think this is leading to using 2 branches - one for the test snapshot,
> then one for the release after someone blesses it.
That seems perfectly workable. I think it requires more merging
because you will need to merge changes from the trunk onto each
branch. But that should still work fine.
> > This is just semantics but it sounds more like a branch than a tag to
> > me. Branches can change and mutate over time. But tags imply
> > something that does not change. In CVS it was just a quirk of the
> > implementation that that tags were also used as cheap branches.
>
> I think of it a different way. In CVS, files are versioned separately
> and tags are the way you identify a set of file versions so you
> can operate on the same set repeatably.
Agreed to this point.
> The files are expected to continue to change and the point of the
> tag is to identify the state of a snapshot of the set.
This is where we diverge. In CVS a tag can move. Or you can choose
never to move it.
A tag such as RELEASE-4.2.1 I would expect never to move from the
files it identifies. But a tag such as LATEST I would expect to float
to the top and always track the HEAD. They are both tags. But the
purpose they are being put to is completely different purposes.
> Normally you would just keep adding new tags with increasing version
> numbers
For RELEASE-4.2.1 I would expect that to never move and never be
deleted. I would expect it to be followed by RELEASE-4.2.2,
RELEASE-4.2.3, RELEASE-4.3.1, etc.
>- and you can do that too if you want but then everyone has to track
>what is the latest tagged version. For this purpose I just want to
>identify the latest file versions that have been tested together for
>current production and the one to use to back it out and floating a
>known tag seems easier than tracking variable ones.
That is the *other* behavior of cvs tags. LATEST would move. But
when LATEST moves the history of where it pointed to previously is
lost. This is not supported by cvs. But svn uses directory trees for
tags and versions tree operations.
> > I think because subversion versions directory trees that you can
> > automate making perfect merges to branches behind the scenes. People
> > would never have to deal with it but a script could easily do so. Of
> > course you have to get it going but then...
> >
> > THEN=$(date +%F-%T)
> > svn copy $URL/trunk $URL/tags/release-$THEN
> > ...work.test.work...
> > ...test.work.test...GOOD.VERSION!...
>
> The catch is that the top line needs to overlap the bottom
> part independently. That is, the tester takes the current
> repository head as his starting point.
I think I covered that. However I did create a very fast and loose
example and admit there are many details "left as an exercise for the
reader". :-)
> Meanwhile developers may commit changes that go into the next cycle.
Yes.
> If the tester finds a problem with one file, with CVS he could fix
> it and commit that file or ask the developer to do it, then update
> that file into his workspace before the rtag operation.
There are different ways to do that change. On a branch? On the main
trunk and then merge back into the branch? On the main trunk and then
just move the tag to the file on the main trunk? In that last case
what if the main trunk has other incompatible changes already?
Could you outline that part in a little more detail?
> If you can't do individual file changes in subversion,
I don't quite agree with that statement.
> I think that means the testing copy has to be on a branch so as not
> to interfere with other concurrent commits on the main trunk that we
> don't want to pick up yet.
That would work just fine.
> But we probably do want the fix the tester adds put
> into the trunk. Does that become a separate operation
> or is there a way to finalize this such that the testing
> workspace can be blessed into a release tag or branch and
> any changes also go back into the trunk where other changes
> may have occurred by now?
Have you seen this best practices reference? I think it is really
pertinent to your problem at hand.
http://svn.collab.net/repos/svn/trunk/doc/user/svn-best-practices.html
Look specifically at the "Know when to create branches" section.
> > NOW=$(date +%F-%T)
> > svn copy -rGOODVERSION $URL/trunk $URL/tags/release-$NOW
> > svn checkout $URL/branch/latest .
>
> I don't want anything else that has been committed to the trunk
> at this point other than what the tester might have changed or
> requested to have changed. Isn't this operation going to pick
> up unrelated new work?
No. Because I specified the -rGOODVERSION it will select specifically
that revision of the trunk. Developers may have committed changes on
top of that version but this will copy it based on the specified
version. New commits will not be copied to the tag.
The hard part of doing it this way is identifying the GOODVERSION
number. That will be something like 42123 or some such number.
People don't work well with those types of numbers. But scripts and
programs can handle it fine to create tags based upon that number and
humans deal with named tags well enough.
> > svn merge $URL/tags/release-$THEN $URL/tags/release-$NOW .
> > svn commit -m "$NOW -- Release latest..."
> > THEN=$NOW
> > ...work.test.work...
> > ...test.work.test...GOOD.VERSION!...
> > NOW=$(date +%F-%T)
> > svn copy -rGOODVERSION $URL/trunk $URL/tags/release-$NOW
> > svn checkout $URL/branch/latest .
> > svn merge $URL/tags/release-$THEN $URL/tags/release-$NOW .
> > svn commit -m "$NOW -- Release latest..."
> > THEN=$NOW
>
> I'm not sure I understand all that but I don't think it is going
> to get the fixes back into the trunk as well as identifying the
> branch/tag exactly as tested.
The process model I was proposing was an unstable trunk where all
development happens on the main trunk. Then a stable branch where
known good snapshots of the trunk are captured with a tag.
A disadvantage is that the main trunk must periodically work and
become a good version so that it can be captured. Or it is an
advantage. This is where different people will have different
opinions.
I consider it an advantage. One of the premises of agile code
development is that the project should be always kept in a releasable
state. Therefore I consider this normal when working in an agile
development environment. If the code is always releasable and always
passing all tests then it is easy to periodically make a release from
the main trunk. Or as in the case above pull changes from the main
trunk into the release branch.
Bob
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Updating a live website with a post-commit hook script
Posted by Les Mikesell <le...@gmail.com>.
On Fri, 2006-06-30 at 01:24 -0600, Bob Proulx wrote:
> > > Tags in Subversion are not like tags in CVS. In CVS, you "apply a
tag
> > > to a file." A tag is a property of a file. (Or so I've heard. I
never
> > > used CVS.)
> >
> > It is, but the main reason you apply them is to group all the files
> > you want at once. That is, if you have updated your working copy at
> > some earlier time and your snapshot passes the testing, you can use
> > the rtag command to apply a specified tag to the repository copy of
> > all the files at the versions you have even if the repository now
has
> > new untested updates. A subsequent checkout/update of that tag will
> > get exactly the same versions as the workspace where the tag was
> > applied.
>
> Tags in CVS are often used like cheap branches. What you describe
> looks like a subversion branch.
Yes - I want a branch that represents exactly the testing workspace
but I only want it to appear to anyone else when testing is complete.
> However in CVS tags can be moved.
> And tag movement is an unversioned operation. No versioning of tags
> exists in CVS. In subversion however all operations are versioned.
The point of the tags is that someone has blessed this particular
group of versioned files, which in CVS are versioned individually.
> This means that the CVS operation of moving tags does not map directly
> to a subversion operation. This is by design because in CVS it is
> possible to completely mess up a repository by moving tags and have no
> history of the action.
Tags don't actually have any effect on the file versioning and moving
them doesn't affect any history. It only affects which file versions
are identified by that tag.
> Avoiding that and making all operations
> versioned in subversion was a design goal.
I think this is leading to using 2 branches - one for the test snapshot,
then one for the release after someone blesses it.
> > > But you could certainly
> > > have a tag called "ready for beta" and simply delete it and
recreate
> > > it when you want to update it.
> >
> > That sounds reasonable. Is there a way to rename existing tags? In
> > the CVS scheme I would use rtag to change the RELEASE tag to
> > RELEASE-1, etc. for a few downrev versions, then add a new RELEASE.
>
> This is just semantics but it sounds more like a branch than a tag to
> me. Branches can change and mutate over time. But tags imply
> something that does not change. In CVS it was just a quirk of the
> implementation that that tags were also used as cheap branches.
I think of it a different way. In CVS, files are versioned separately
and tags are the way you identify a set of file versions so you
can operate on the same set repeatably. The files are expected to
continue to change and the point of the tag is to identify the
state of a snapshot of the set. Normally you would just keep adding
new tags with increasing version numbers - and you can do that too if
you want but then everyone has to track what is the latest tagged
version. For this purpose I just want to identify the latest file
versions that have been tested together for current production and the
one to use to back it out and floating a known tag seems easier than
tracking variable ones.
> > > Why is merging not an option?
> >
> > The idea is to make the system foolproof so you can have different
> > groups coding, testing, and installing and the only way code gets
> > to production is by the testers marking it as ready in the
repository.
> > Developers should never have to stop modifying the trunk and the
> > installers shouldn't have to keep track of anything to get the
> > latest known-working version.
>
> I think what you just said is that people should not be merging the
> data. In the situation you describe I can agree with that.
>
> > Since subversion naturally groups files in a commit, maybe the
> > tagging operation isn't needed to identify a snapshot but you
> > still need a way to mark the points that have been tested.
>
> I think because subversion versions directory trees that you can
> automate making perfect merges to branches behind the scenes. People
> would never have to deal with it but a script could easily do so. Of
> course you have to get it going but then...
>
> THEN=$(date +%F-%T)
> svn copy $URL/trunk $URL/tags/release-$THEN
> ...work.test.work...
> ...test.work.test...GOOD.VERSION!...
The catch is that the top line needs to overlap the bottom
part independently. That is, the tester takes the current
repository head as his starting point. Meanwhile developers
may commit changes that go into the next cycle. If the
tester finds a problem with one file, with CVS he could
fix it and commit that file or ask the developer to do it,
then update that file into his workspace before the rtag
operation. If you can't do individual file changes in
subversion, I think that means the testing copy has to be
on a branch so as not to interfere with other concurrent
commits on the main trunk that we don't want to pick up
yet. But we probably do want the fix the tester adds put
into the trunk. Does that become a separate operation
or is there a way to finalize this such that the testing
workspace can be blessed into a release tag or branch and
any changes also go back into the trunk where other changes
may have occurred by now?
> NOW=$(date +%F-%T)
> svn copy -rGOODVERSION $URL/trunk $URL/tags/release-$NOW
> svn checkout $URL/branch/latest .
I don't want anything else that has been committed to the trunk
at this point other than what the tester might have changed or
requested to have changed. Isn't this operation going to pick
up unrelated new work?
> svn merge $URL/tags/release-$THEN $URL/tags/release-$NOW .
> svn commit -m "$NOW -- Release latest..."
> THEN=$NOW
> ...work.test.work...
> ...test.work.test...GOOD.VERSION!...
> NOW=$(date +%F-%T)
> svn copy -rGOODVERSION $URL/trunk $URL/tags/release-$NOW
> svn checkout $URL/branch/latest .
> svn merge $URL/tags/release-$THEN $URL/tags/release-$NOW .
> svn commit -m "$NOW -- Release latest..."
> THEN=$NOW
I'm not sure I understand all that but I don't think it is going
to get the fixes back into the trunk as well as identifying the
branch/tag exactly as tested.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Updating a live website with a post-commit hook script
Posted by Les Mikesell <le...@futuresource.com>.
On Fri, 2006-06-30 at 01:24 -0600, Bob Proulx wrote:
> > > Tags in Subversion are not like tags in CVS. In CVS, you "apply a tag
> > > to a file." A tag is a property of a file. (Or so I've heard. I never
> > > used CVS.)
> >
> > It is, but the main reason you apply them is to group all the files
> > you want at once. That is, if you have updated your working copy at
> > some earlier time and your snapshot passes the testing, you can use
> > the rtag command to apply a specified tag to the repository copy of
> > all the files at the versions you have even if the repository now has
> > new untested updates. A subsequent checkout/update of that tag will
> > get exactly the same versions as the workspace where the tag was
> > applied.
>
> Tags in CVS are often used like cheap branches. What you describe
> looks like a subversion branch.
Yes - I want a branch that represents exactly the testing workspace
but I only want it to appear to anyone else when testing is complete.
> However in CVS tags can be moved.
> And tag movement is an unversioned operation. No versioning of tags
> exists in CVS. In subversion however all operations are versioned.
The point of the tags is that someone has blessed this particular
group of versioned files, which in CVS are versioned individually.
> This means that the CVS operation of moving tags does not map directly
> to a subversion operation. This is by design because in CVS it is
> possible to completely mess up a repository by moving tags and have no
> history of the action.
Tags don't actually have any effect on the file versioning and moving
them doesn't affect any history. It only affects which file versions
are identified by that tag.
> Avoiding that and making all operations
> versioned in subversion was a design goal.
I think this is leading to using 2 branches - one for the test snapshot,
then one for the release after someone blesses it.
> > > But you could certainly
> > > have a tag called "ready for beta" and simply delete it and recreate
> > > it when you want to update it.
> >
> > That sounds reasonable. Is there a way to rename existing tags? In
> > the CVS scheme I would use rtag to change the RELEASE tag to
> > RELEASE-1, etc. for a few downrev versions, then add a new RELEASE.
>
> This is just semantics but it sounds more like a branch than a tag to
> me. Branches can change and mutate over time. But tags imply
> something that does not change. In CVS it was just a quirk of the
> implementation that that tags were also used as cheap branches.
I think of it a different way. In CVS, files are versioned separately
and tags are the way you identify a set of file versions so you
can operate on the same set repeatably. The files are expected to
continue to change and the point of the tag is to identify the
state of a snapshot of the set. Normally you would just keep adding
new tags with increasing version numbers - and you can do that too if
you want but then everyone has to track what is the latest tagged
version. For this purpose I just want to identify the latest file
versions that have been tested together for current production and the
one to use to back it out and floating a known tag seems easier than
tracking variable ones.
> > > Why is merging not an option?
> >
> > The idea is to make the system foolproof so you can have different
> > groups coding, testing, and installing and the only way code gets
> > to production is by the testers marking it as ready in the repository.
> > Developers should never have to stop modifying the trunk and the
> > installers shouldn't have to keep track of anything to get the
> > latest known-working version.
>
> I think what you just said is that people should not be merging the
> data. In the situation you describe I can agree with that.
>
> > Since subversion naturally groups files in a commit, maybe the
> > tagging operation isn't needed to identify a snapshot but you
> > still need a way to mark the points that have been tested.
>
> I think because subversion versions directory trees that you can
> automate making perfect merges to branches behind the scenes. People
> would never have to deal with it but a script could easily do so. Of
> course you have to get it going but then...
>
> THEN=$(date +%F-%T)
> svn copy $URL/trunk $URL/tags/release-$THEN
> ...work.test.work...
> ...test.work.test...GOOD.VERSION!...
The catch is that the top line needs to overlap the bottom
part independently. That is, the tester takes the current
repository head as his starting point. Meanwhile developers
may commit changes that go into the next cycle. If the
tester finds a problem with one file, with CVS he could
fix it and commit that file or ask the developer to do it,
then update that file into his workspace before the rtag
operation. If you can't do individual file changes in
subversion, I think that means the testing copy has to be
on a branch so as not to interfere with other concurrent
commits on the main trunk that we don't want to pick up
yet. But we probably do want the fix the tester adds put
into the trunk. Does that become a separate operation
or is there a way to finalize this such that the testing
workspace can be blessed into a release tag or branch and
any changes also go back into the trunk where other changes
may have occurred by now?
> NOW=$(date +%F-%T)
> svn copy -rGOODVERSION $URL/trunk $URL/tags/release-$NOW
> svn checkout $URL/branch/latest .
I don't want anything else that has been committed to the trunk
at this point other than what the tester might have changed or
requested to have changed. Isn't this operation going to pick
up unrelated new work?
> svn merge $URL/tags/release-$THEN $URL/tags/release-$NOW .
> svn commit -m "$NOW -- Release latest..."
> THEN=$NOW
> ...work.test.work...
> ...test.work.test...GOOD.VERSION!...
> NOW=$(date +%F-%T)
> svn copy -rGOODVERSION $URL/trunk $URL/tags/release-$NOW
> svn checkout $URL/branch/latest .
> svn merge $URL/tags/release-$THEN $URL/tags/release-$NOW .
> svn commit -m "$NOW -- Release latest..."
> THEN=$NOW
I'm not sure I understand all that but I don't think it is going
to get the fixes back into the trunk as well as identifying the
branch/tag exactly as tested.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Updating a live website with a post-commit hook script
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Jun 30, 2006, at 09:24, Bob Proulx wrote:
> Tags in CVS are often used like cheap branches. What you describe
> looks like a subversion branch. However in CVS tags can be moved.
> And tag movement is an unversioned operation. No versioning of tags
> exists in CVS. In subversion however all operations are versioned.
Just to be entirely clear, Subversion does also have some unversioned
properties (like svn:log)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Updating a live website with a post-commit hook script
Posted by Bob Proulx <bo...@proulx.com>.
Les Mikesell wrote:
> Ryan Schmidt wrote:
> > Tags in Subversion are not like tags in CVS. In CVS, you "apply a tag
> > to a file." A tag is a property of a file. (Or so I've heard. I never
> > used CVS.)
>
> It is, but the main reason you apply them is to group all the files
> you want at once. That is, if you have updated your working copy at
> some earlier time and your snapshot passes the testing, you can use
> the rtag command to apply a specified tag to the repository copy of
> all the files at the versions you have even if the repository now has
> new untested updates. A subsequent checkout/update of that tag will
> get exactly the same versions as the workspace where the tag was
> applied.
Tags in CVS are often used like cheap branches. What you describe
looks like a subversion branch. However in CVS tags can be moved.
And tag movement is an unversioned operation. No versioning of tags
exists in CVS. In subversion however all operations are versioned.
This means that the CVS operation of moving tags does not map directly
to a subversion operation. This is by design because in CVS it is
possible to completely mess up a repository by moving tags and have no
history of the action. Avoiding that and making all operations
versioned in subversion was a design goal.
> > But you could certainly
> > have a tag called "ready for beta" and simply delete it and recreate
> > it when you want to update it.
>
> That sounds reasonable. Is there a way to rename existing tags? In
> the CVS scheme I would use rtag to change the RELEASE tag to
> RELEASE-1, etc. for a few downrev versions, then add a new RELEASE.
This is just semantics but it sounds more like a branch than a tag to
me. Branches can change and mutate over time. But tags imply
something that does not change. In CVS it was just a quirk of the
implementation that that tags were also used as cheap branches.
> > Why is merging not an option?
>
> The idea is to make the system foolproof so you can have different
> groups coding, testing, and installing and the only way code gets
> to production is by the testers marking it as ready in the repository.
> Developers should never have to stop modifying the trunk and the
> installers shouldn't have to keep track of anything to get the
> latest known-working version.
I think what you just said is that people should not be merging the
data. In the situation you describe I can agree with that.
> Since subversion naturally groups files in a commit, maybe the
> tagging operation isn't needed to identify a snapshot but you
> still need a way to mark the points that have been tested.
I think because subversion versions directory trees that you can
automate making perfect merges to branches behind the scenes. People
would never have to deal with it but a script could easily do so. Of
course you have to get it going but then...
THEN=$(date +%F-%T)
svn copy $URL/trunk $URL/tags/release-$THEN
...work.test.work...
...test.work.test...GOOD.VERSION!...
NOW=$(date +%F-%T)
svn copy -rGOODVERSION $URL/trunk $URL/tags/release-$NOW
svn checkout $URL/branch/latest .
svn merge $URL/tags/release-$THEN $URL/tags/release-$NOW .
svn commit -m "$NOW -- Release latest..."
THEN=$NOW
...work.test.work...
...test.work.test...GOOD.VERSION!...
NOW=$(date +%F-%T)
svn copy -rGOODVERSION $URL/trunk $URL/tags/release-$NOW
svn checkout $URL/branch/latest .
svn merge $URL/tags/release-$THEN $URL/tags/release-$NOW .
svn commit -m "$NOW -- Release latest..."
THEN=$NOW
Or something similar.
Bob
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Updating a live website with a post-commit hook script
Posted by Les Mikesell <le...@gmail.com>.
On Thu, 2006-06-29 at 21:57 +0200, Ryan Schmidt wrote:
> Tags in Subversion are not like tags in CVS. In CVS, you "apply a tag
> to a file." A tag is a property of a file. (Or so I've heard. I never
> used CVS.)
It is, but the main reason you apply them is to group all the files
you want at once. That is, if you have updated your working copy at
some earlier time and your snapshot passes the testing, you can use
the rtag command to apply a specified tag to the repository copy of
all the files at the versions you have even if the repository now has
new untested updates. A subsequent checkout/update of that tag will
get exactly the same versions as the workspace where the tag was
applied.
> In Subversion, you copy the trunk (or the branch you're
> working on) to a directory called tags. And that's it. Usually you'd
> give each tag a new version number or date.
Then you'd have to keep track of the versions that are supposed to
be installed - and to back out you'd need the last known-to-work
version.
> But you could certainly
> have a tag called "ready for beta" and simply delete it and recreate
> it when you want to update it.
That sounds reasonable. Is there a way to rename existing tags? In
the CVS scheme I would use rtag to change the RELEASE tag to
RELEASE-1, etc. for a few downrev versions, then add a new RELEASE.
> Why is merging not an option?
The idea is to make the system foolproof so you can have different
groups coding, testing, and installing and the only way code gets
to production is by the testers marking it as ready in the repository.
Developers should never have to stop modifying the trunk and the
installers shouldn't have to keep track of anything to get the
latest known-working version.
Since subversion naturally groups files in a commit, maybe the
tagging operation isn't needed to identify a snapshot but you
still need a way to mark the points that have been tested.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Updating a live website with a post-commit hook script
Posted by "Daniell, Casey B" <Ca...@reyrey.com>.
Correct in CVS a tag is a property of a files, so you are in effect
pulling the version of the file with the tag applied to it. I understand
how tags work in subversion, but was trying to find another way to
function with the same basic results.
The team that is doing the development is very much, NOT a development
type organization as such I wanted to stay away from merging as much as
possible, especially since they may encounter merge conflicts.
Additionally, it will be hard for them to track what they have,
effectively, on what branch. I would be much more comfortable with them
moving a floating tag and just grabbing a particular tag with a
post-commit hooks scripts, that fires in each environment.
Casey
-----Original Message-----
From: Ryan Schmidt [mailto:subversion-2006q2@ryandesign.com]
Sent: Thursday, June 29, 2006 2:58 PM
To: Daniell, Casey B
Cc: Les Mikesell; jason@subversus.org; Rainer Sokoll;
users@subversion.tigris.org
Subject: Re: Updating a live website with a post-commit hook script
On Jun 29, 2006, at 21:39, Daniell, Casey B wrote:
>> Slight variation on the question: how would you make the site stay at
>> a tagged version so untested changes could be committed, then tested
>> and tagged when verified? I used to do this with CVS by rtagging the
>> tested copy to float a known tag to that version, followed by an
>> update to the working version, always using the same tag. That way it
>> didn't matter if additional untested changes had been committed.
>> The script also floated a couple of previous-release tags backwards
>> so you could always back out to earlier versions without having to
>> track any release numbers or tags.
>
> If anyone has suggestions on how to accomplish this I would love to
> hear them as well.
>
> We are currently managing 1000s of websites each with their own
> stylesheets/images ect. Having that team perform merges is not an
> option unless, so the idea of a floating tag similar to CVS, or CC is
> the most appealing. This way the customization guys and set a
> rdy_for_beta or rdy_for_prod type tag on their changes which is
> automatically push at specific times during the day via a svn update.
Tags in Subversion are not like tags in CVS. In CVS, you "apply a tag to
a file." A tag is a property of a file. (Or so I've heard. I never used
CVS.) In Subversion, you copy the trunk (or the branch you're working
on) to a directory called tags. And that's it. Usually you'd give each
tag a new version number or date. But you could certainly have a tag
called "ready for beta" and simply delete it and recreate it when you
want to update it.
Why is merging not an option?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Updating a live website with a post-commit hook script
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Jun 29, 2006, at 21:39, Daniell, Casey B wrote:
>> Slight variation on the question: how would you make the site stay
>> at a
>> tagged version so untested changes could be committed, then tested
>> and
>> tagged when verified? I used to do this with CVS by rtagging the
>> tested
>> copy to float a known tag to that version, followed by an update
>> to the
>> working version, always using the same tag. That way it didn't
>> matter if
>> additional untested changes had been committed.
>> The script also floated a couple of previous-release tags
>> backwards so
>> you could always back out to earlier versions without having to track
>> any release numbers or tags.
>
> If anyone has suggestions on how to accomplish this I would love to
> hear
> them as well.
>
> We are currently managing 1000s of websites each with their own
> stylesheets/images ect. Having that team perform merges is not an
> option
> unless, so the idea of a floating tag similar to CVS, or CC is the
> most
> appealing. This way the customization guys and set a rdy_for_beta or
> rdy_for_prod type tag on their changes which is automatically push at
> specific times during the day via a svn update.
Tags in Subversion are not like tags in CVS. In CVS, you "apply a tag
to a file." A tag is a property of a file. (Or so I've heard. I never
used CVS.) In Subversion, you copy the trunk (or the branch you're
working on) to a directory called tags. And that's it. Usually you'd
give each tag a new version number or date. But you could certainly
have a tag called "ready for beta" and simply delete it and recreate
it when you want to update it.
Why is merging not an option?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: RE: Updating a live website with a post-commit hook script
Posted by "Daniell, Casey B" <Ca...@reyrey.com>.
If anyone has suggestions on how to accomplish this I would love to hear
them as well.
We are currently managing 1000s of websites each with their own
stylesheets/images ect. Having that team perform merges is not an option
unless, so the idea of a floating tag similar to CVS, or CC is the most
appealing. This way the customization guys and set a rdy_for_beta or
rdy_for_prod type tag on their changes which is automatically push at
specific times during the day via a svn update.
Casey
On Thu, 2006-06-29 at 11:53 -0400, jason@subversus.org wrote:
> You've asked the question and gotten several responses saying that you
> either can't do what you want, or that what you want to do can be done
> much easier by simply using post-commit hooks to update a working copy
> that can be served by Apache. Yet you keep arguing.
>
> If you think all of those responses are wrong, wouldn't it be easier
> to go and try it out and if those responses were proved incorrect
> (unlikely) to provide this new-found knowledge back to the mailing
list?
Slight variation on the question: how would you make the site stay at a
tagged version so untested changes could be committed, then tested and
tagged when verified? I used to do this with CVS by rtagging the tested
copy to float a known tag to that version, followed by an update to the
working version, always using the same tag. That way it didn't matter if
additional untested changes had been committed.
The script also floated a couple of previous-release tags backwards so
you could always back out to earlier versions without having to track
any release numbers or tags.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Updating a live website with a post-commit hook script
Posted by Les Mikesell <le...@gmail.com>.
On Thu, 2006-06-29 at 11:53 -0400, jason@subversus.org wrote:
> You've asked the question and gotten several responses saying that you
> either can't do what you want, or that what you want to do can be done much
> easier by simply using post-commit hooks to update a working copy that can
> be served by Apache. Yet you keep arguing.
>
> If you think all of those responses are wrong, wouldn't it be easier to go
> and try it out and if those responses were proved incorrect (unlikely) to
> provide this new-found knowledge back to the mailing list?
Slight variation on the question: how would you make the site stay
at a tagged version so untested changes could be committed, then
tested and tagged when verified? I used to do this with CVS by
rtagging the tested copy to float a known tag to that version, followed
by an update to the working version, always using the same tag. That
way it didn't matter if additional untested changes had been committed.
The script also floated a couple of previous-release tags backwards
so you could always back out to earlier versions without having to
track any release numbers or tags.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Updating a live website with a post-commit hook script
Posted by ja...@subversus.org.
You've asked the question and gotten several responses saying that you
either can't do what you want, or that what you want to do can be done much
easier by simply using post-commit hooks to update a working copy that can
be served by Apache. Yet you keep arguing.
If you think all of those responses are wrong, wouldn't it be easier to go
and try it out and if those responses were proved incorrect (unlikely) to
provide this new-found knowledge back to the mailing list?
-----Original Message-----
From: Rainer Sokoll [mailto:r.sokoll@intershop.de]
Sent: Thursday, June 29, 2006 11:00 AM
Cc: users@subversion.tigris.org
Subject: Re: Updating a live website with a post-commit hook script
Greg Thomas wrote:
> On Thu, 29 Jun 2006 15:23:51 +0200, Rainer Sokoll
> <r....@intershop.de> wrote:
>>What if svn:mime-type is set to application/x-httpd-php?
>
> The MIME type of a file only affects how the client displays it. PHP
> etc. code is processed server side.
[The discussion goes slightly off topic, but I cannot stop myself ;-)]
I disagree.
To my best knowledge:
If you do not have somewhere in your apache config:
"AddType application/x-httpd-php .php" or "application/x-httpd-php php" in
mime.types
then apache will deliver the contents of your php file as text/plain.
If you have one of the statements above, apache will pass the php file to
mod_php (if DSO is supported) and then deliver whatever the php script
returns.
So my question is: Does mod_svn give back its results to apache for further
processing (for example mod_php) or not?
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Updating a live website with a post-commit hook script
Posted by Rainer Sokoll <r....@intershop.de>.
Greg Thomas wrote:
> On Thu, 29 Jun 2006 15:23:51 +0200, Rainer Sokoll
> <r....@intershop.de> wrote:
>>What if svn:mime-type is set to application/x-httpd-php?
>
> The MIME type of a file only affects how the client displays it. PHP
> etc. code is processed server side.
[The discussion goes slightly off topic, but I cannot stop myself ;-)]
I disagree.
To my best knowledge:
If you do not have somewhere in your apache config:
"AddType application/x-httpd-php .php" or
"application/x-httpd-php php" in mime.types
then apache will deliver the contents of your php file as text/plain.
If you have one of the statements above, apache will pass the php file
to mod_php (if DSO is supported) and then deliver whatever the php
script returns.
So my question is: Does mod_svn give back its results to apache for
further processing (for example mod_php) or not?
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Updating a live website with a post-commit hook script
Posted by Greg Thomas <th...@omc.bt.co.uk>.
On Thu, 29 Jun 2006 15:23:51 +0200, Rainer Sokoll
<r....@intershop.de> wrote:
>> If your repository contains PHP files, for example, and you want to
>> see the web site and have the PHP code evaluated, then the above
>> VirtualHost is not sufficient, because Subversion will show the PHP
>> source code, and will not pass it back to the Apache PHP module to
>> have it interpreted.
>
>What if svn:mime-type is set to application/x-httpd-php?
The MIME type of a file only affects how the client displays it. PHP
etc. code is processed server side.
Greg
--
This post represents the views of the author and does
not necessarily accurately represent the views of BT.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Updating a live website with a post-commit hook script
Posted by Rainer Sokoll <r....@intershop.de>.
Ryan Schmidt wrote:
>> Then point the webroot to <repos>/trunk/
> And to access the trunk, you have to visit the URL http://
> some.hostname/trunk. You cannot point SVNPath at /path/to/the/repo/
> trunk because "trunk" is not a repository; it is a path within the
> repository.
Ok, I got it. You are right as long as the real stuff is in a subdir
like /trunk/, which is best practice.
>>> b) it only works if you have exclusively static files. As soon as you
>>> have any SSI or PHP or ASP or JSP or anything else dynamic, it can't
>>> work,
>>
>> Sorry, I don't see the point. Can you be more verbose?
>
> If your repository contains PHP files, for example, and you want to
> see the web site and have the PHP code evaluated, then the above
> VirtualHost is not sufficient, because Subversion will show the PHP
> source code, and will not pass it back to the Apache PHP module to
> have it interpreted.
What if svn:mime-type is set to application/x-httpd-php?
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Updating a live website with a post-commit hook script
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Jun 29, 2006, at 14:14, Rainer Sokoll wrote:
> Ryan Schmidt wrote:
>
>>> Why not having the document root pointing to the subversion
>>> repository?
>>> As long as svn:mime-type is set properly, this should work?
>>
>> a) if you're following best practices, you have a trunk and branches
>> and tags. So you'd always have to type "/trunk" into the URL to see
>> the web site. Fine for development but a bit ugly otherwise.
>
> Then point the webroot to <repos>/trunk/
That's not possible. Imagine a repo containing trunk, branches and
tags at the top level. You want to serve this via Apache. Your Apache
conf has to look something like this:
<VirtualHost *:80>
ServerName some.hostname
<Location />
DAV svn
SVNPath /path/to/the/repo
</Location>
</VirtualHost>
And to access the trunk, you have to visit the URL http://
some.hostname/trunk. You cannot point SVNPath at /path/to/the/repo/
trunk because "trunk" is not a repository; it is a path within the
repository.
>> b) it only works if you have exclusively static files. As soon as you
>> have any SSI or PHP or ASP or JSP or anything else dynamic, it can't
>> work,
>
> Sorry, I don't see the point. Can you be more verbose?
If your repository contains PHP files, for example, and you want to
see the web site and have the PHP code evaluated, then the above
VirtualHost is not sufficient, because Subversion will show the PHP
source code, and will not pass it back to the Apache PHP module to
have it interpreted.
No, there really are reasons why the FAQ says you need to check out a
working copy and point Apache at that: because that's what works.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Updating a live website with a post-commit hook script
Posted by Rainer Sokoll <r....@intershop.de>.
Ryan Schmidt wrote:
>> Why not having the document root pointing to the subversion
>> repository?
>> As long as svn:mime-type is set properly, this should work?
>
> a) if you're following best practices, you have a trunk and branches
> and tags. So you'd always have to type "/trunk" into the URL to see
> the web site. Fine for development but a bit ugly otherwise.
Then point the webroot to <repos>/trunk/
> b) it only works if you have exclusively static files. As soon as you
> have any SSI or PHP or ASP or JSP or anything else dynamic, it can't
> work,
Sorry, I don't see the point. Can you be more verbose?
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Updating a live website with a post-commit hook script
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Jun 29, 2006, at 13:37, Rainer Sokoll wrote:
> Bob Proulx wrote:
>> Graham Anderson wrote:
>>> 1) Is there an example script and tutorial on how to update a live
>>> web site with a post-commit hook script ?
>
>> Let's assume a subversion repository at /srv/svn/www and a web
>> document root at /srv/www. You could have a post-commit hook at
>> /srv/svn/www/hooks/post-commit with this content:
>
> Why not having the document root pointing to the subversion
> repository?
> As long as svn:mime-type is set properly, this should work?
a) if you're following best practices, you have a trunk and branches
and tags. So you'd always have to type "/trunk" into the URL to see
the web site. Fine for development but a bit ugly otherwise.
b) it only works if you have exclusively static files. As soon as you
have any SSI or PHP or ASP or JSP or anything else dynamic, it can't
work, and you need to do it the way described earlier in the thread,
with the working copy that gets updated.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Updating a live website with a post-commit hook script
Posted by Rainer Sokoll <r....@intershop.de>.
Bob Proulx wrote:
> Graham Anderson wrote:
>> 1) Is there an example script and tutorial on how to update a live
>> web site with a post-commit hook script ?
> Let's assume a subversion repository at /srv/svn/www and a web
> document root at /srv/www. You could have a post-commit hook at
> /srv/svn/www/hooks/post-commit with this content:
Why not having the document root pointing to the subversion repository?
As long as svn:mime-type is set properly, this should work?
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Updating a live website with a post-commit hook script
Posted by Bob Proulx <bo...@proulx.com>.
Graham Anderson wrote:
> 1) Is there an example script and tutorial on how to update a live
> web site with a post-commit hook script ?
I don't know if official examples exist but the implementation is
really only a few lines.
> 2) Does this comply with a 'best practices' use for subversion ? At
> this point, I am a bit too green to evaluate if this is ok.
Yes. This is a best practice. It is recommended in the FAQ as you
noted in your message.
http://subversion.tigris.org/faq.html#website-auto-update
Let's assume a subversion repository at /srv/svn/www and a web
document root at /srv/www. You could have a post-commit hook at
/srv/svn/www/hooks/post-commit with this content:
#!/bin/sh
cd /srv/www || exit 1
svn update --quiet
exit 0
A very simple process. Change directory to the live web working copy
and update it.
This process will run as the web process uid. On my machine that
means the www-data user. On other machines it will be different. The
live working copy needs to be owned by the www-data user or at least
be writable by it so that the web server uid can update it.
Of course you don't need to use the https:// protocol to update. You
could use the svn+ssh:// protocol. But if you are updating a web page
then we can assume that you have a web server and so have https://
available. This avoids a permission problem.
If you use svn+ssh:// then the post-commit is run as the committing
uid which will be different for everyone. For a web server document
root keeping it writable by everyone is probably not what you want to
do. This is where the little C program wrapper described in the FAQ
becomes useful. Set up a set-uid program to switch to a pseudo user
to update the web document root. Make it writable only by that pseudo
user.
Hope that helps!
Bob
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Updating a live website with a post-commit hook script
Posted by Sergey Volkov <se...@realeastnetworks.com>.
Hello
I having one repositry serving a couple of web-projects.
I use the following python script to update web-server working copyes.
Hope this will help.
-------------------------------------------------------------
#!/usr/bin/python
import sys
import os
result = 1
# get repo->local copy dictionary
filename = '/var/svn/hooks/web-conf.py'
if filename and os.path.isfile(filename):
execfile(filename)
else:
sys.exit('Unable to execute ' + filename)
# get repository and revision from args
try:
repository = sys.argv[1]
revision = sys.argv[2]
except IndexError:
sys.exit('Not enought parameters given')
# find working copy for passed repository
try:
local_copy = local_copyes[repository]
except KeyError:
sys.exit('Couldn\'t get working copy for given repository...')
# get list of changed directories
fd=os.popen('svnlook -r ' + revision + ' dirs-changed ' + repository)
changed_dir_list = fd.readlines()
fd.close()
# get the top dir changed
try:
top_changed_dir = os.path.commonprefix(changed_dir_list).strip()
except IndexError:
sys.exit('No dir\'s changed by this commit')
update_path = local_copy + top_changed_dir
if os.path.isdir(update_path):
result = os.system('svn update ' + update_path)
else:
sys.exit('Sorry, \'' + update_path + '\' is not a directory...')
sys.exit(result)
------------------------------------------------------------
Contents of the /var/svn/hooks/web-conf.py :
local_copyes = {
'/var/svn/test': '/tmp/wwwsvn/test/',
'/var/svn/web': '/var/www/'
}
On Thu, 29 Jun 2006 04:58:41 +0400, Graham Anderson <gr...@siren.cc>
wrote:
> Hi
>
> 1) Is there an example script and tutorial on how to update a live web
> site with a post-commit hook script ?
> 2) Does this comply with a 'best practices' use for subversion ? At
> this point, I am a bit too green to evaluate if this is ok.
>
> I am very new to subversion so any help is appreciated.
>
> From: http://subversion.tigris.org/faq.html
>> I'm managing a website in my repository. How can I make the live site
>> automatically update after every commit?
>>
>> This is done all the time, and is easily accomplished by adding a
>> post-commit hook script to your repository. Read about hook scripts in
>> Chapter 5 of the book. The basic idea is to make the "live site" just
>> an ordinary working copy, and then have your post-commit hook script
>> run 'svn update' on it.
>
>
>
>
>
> many thanks
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
--
Sergey Volkov
Internet Applications Team Leader
RealEast Networks LLC
http://www.realeastnetworks.com
mailto: sergeyv@realeastnetworks.com
gmail: Serg.Volkov@gmail.com
ICQ: 117726485
JID: sergeyv@nnov.stelt.ru
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Updating a live website with a post-commit hook script
Posted by Duane Griffin <d....@psenterprise.com>.
Hi Graham,
On Wed, 2006-06-28 at 17:58 -0700, Graham Anderson wrote:
> 1) Is there an example script and tutorial on how to update a live
> web site with a post-commit hook script ?
IMO, and as others have mentioned, the best way of doing things is to
use "svn up" on the web-server to prepare a staging area, then switch
over to it atomically by changing a symlink. If for some reason you want
to use a different mechanism (e.g. you don't have subversion on your
web-server) you can use a post-commit hook to prepare a staging area
with the changes and then upload them using rsync or something similar.
Some time ago I was playing around with this sort of thing and posted a
script we were using to the list. It uploads files using scp and should
be easy to adapt, at least if you know perl. All the meta-data it uses
(destination to upload to, etc) it takes from subversion properties.
This allows you to use one repository and post-commit hook to manage
several different sites.
You can find the script here:
http://svn.haxx.se/users/archive-2005-04/att-1537/commit-upload.pl
I no longer use it myself, but if you have any questions I'll try my
best to answer them.
> 2) Does this comply with a 'best practices' use for subversion ? At
> this point, I am a bit too green to evaluate if this is ok.
>
> I am very new to subversion so any help is appreciated.
Regards,
Duane.
--
Duane Griffin
Senior Software Developer
Process Systems Enterprise Limited - "The model company"
Bridge Studios, 107a Hammersmith Bridge Road, London W6 9DA
Call +44 (0)20 8563 0888 or visit us at www.psenterprise.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org