ANN: A new subversion SCM module

[wolfmanjm]

I'd like to announce a new subversion SCM module for Capistrano.

In addition to all the old functionality, it adds three new features.

1. Handles the subversion repository only being accessible from the
local machine
2. Handles the subversion repository URL being different on local host
and remote server
3. Handles different paths to svn binary on local host and remote
server

Details of this module can be read here:
http://blog.wolfman.com/articles/2006/12/06/a-capistrano-scm-module-for-local-svn-access

I will also upload the file to this group (if it allows me to).

The file includes an extended subversion_test.rb for unit testing.

This version is Beta, please test if you have a need for its
functionality.

Jamis... You are welcome to replace the current scm/subversion.rb with
this one if you like (hint, hint ;)

[Mike Bailey]

Good stuff. A lot of people can't have their SCM accessible from the
server they deploy to.

I like to release often. Rather than uploading the whole project
every time and flooding my uplink, how about
using rsync over ssh? How much work would be involved to put rsync
into actor? Are there any hooks in Net:SSH that allow running
something like this?

cheers,

Mike

[wolfmanjm]

Thats a good point, I think rather than using rsync I can probably just
get the changed files from svn, tar those up,
then copy the current directory on the server, then merge the changed
files. kind of tricky though, because capistrano needs
to keep the old copy which it does outside of the scm.

[Geoffrey Grosenbach]

On Thu, Dec 07, 2006 at 05:58:15PM +1100, Mike Bailey wrote:
> I like to release often. Rather than uploading the whole project
> every time and flooding my uplink, how about
> using rsync over ssh? How much work would be involved to put rsync
> into actor? Are there any hooks in Net:SSH that allow running
> something like this?

Or, try this add-on that keeps a copy of your svn app in "shared" and updates it instead of doing a full checkout each time.

http://pastie.caboo.se/24849

I've added a flag to --exclude=".svn" so my svn files aren't on the public side of the server.

I'm putting together a gem that will include this and other hacks.

Geoff

[wolfmanjm]

That technique will not work if the server cannot access the subversion
repository, which is the whole point of my version.

If the server does have access to the svn server them I'm not sure I
really understand what the advantage of that cache is though,
as you can simply do an update directly on the current directory,
therefore only getting the new files. (cap -a update).

On Dec 7, 9:20 am, Geoffrey Grosenbach <b...@topfunky.com> wrote:
> On Thu, Dec 07, 2006 at 05:58:15PM +1100, Mike Bailey wrote:
> > I like to release often. Rather than uploading the whole project
> > every time and flooding my uplink, how about
> > using rsync over ssh? How much work would be involved to put rsync
> > into actor? Are there any hooks in Net:SSH that allow running

> > something like this?Or, try this add-on that keeps a copy of your svn app in "shared" and updates it instead of doing a full checkout each time.

[Mike Bailey]

Jim's solved the problem of 'how do I deploy my app to servers with
no access to the SCM server'.
His extension does that by uploading the entire project from the
deployers workstation.

From reading the code in the pastie, it doesn't appear to support
this use case.

- Mike

[Jamis Buck]

I've been thinking long and hard about this. It's definitely a move
in the right direction, but I think it needs to be approached
differently, which is why I haven't added this to trunk yet.

My current thinking is this: sometime after the next release of
capistrano (which will be Real Soon Now), I'd like to decouple the
deployment method from the SCM. Currently, the two are too tightly
coupled, which requires people to jump through lots of hoops to
separate them.

What I'm thinking is that each SCM module would simply become
something that could be queried for the instructions needed to
execute some task. For example, something like the following pseudo-
code:

svn = SCM::Subversion.new(config)
p svn.checkout #-> "svn co -r1234 svn+ssh://foo.bar.com/svn/trunk /
u/apps/foo/releases/12345"
p svn.export #-> "svn export -r1234 svn+ssh://foo.bar.com/svn/
trunk /u/apps/foo/releases/12345"

Then, the deployment method can be decoupled from the SCM:

set :scm, :subversion
# set :scm, :darcs
# set :scm, :baz
# etc.

set :deploy_via, :checkout
# set :deploy_via, :export
# set :deploy_via, :copy
# set :deploy_via, :rsync
# etc.

The important thing is to make sure a record is kept (consistently)
on the server of what the currently deployed revision is, so that
features like "diff_from_last_deploy" still work.

I'll probably start working on that refactoring sometime after
Christmas.

- Jamis

[wolfmanjm]

sounds like a good idea, I look forward to seeing it.

will you include a way to deploy when the scm is not accessible from
the server?
if not I'll be happy to implement that part, as I realize you don't
need that use case.

thanks

[Jamis Buck]

On Dec 23, 2006, at 2:01 PM, wolfmanjm wrote:

>
> sounds like a good idea, I look forward to seeing it.
>
> will you include a way to deploy when the scm is not accessible from
> the server?
> if not I'll be happy to implement that part, as I realize you don't
> need that use case.

I probably will, just because it has become the canonical use-case
for a deployment scenario that needs to be decoupled from the SCM in
use, and if I can get that case right, then I've probably got the
refactoring correct. (It corresponds to the "set :deploy_via, :copy"
example I gave earlier.)

- Jamis

[wolfmanjm]

As suggested by a number of people I have updated this SCM module to
use rsync as an option.
I uploaded to the files section of this group and I updated my Blog
entry.

The file is now called local_subversion_rsync.rb and the class name
changed too.
This should be fully backward compatible too with the previous
versions and the standard svn scm module.

http://blog.wolfman.com/articles/2006/12/06/a-capistrano-scm-module-for-local-svn-access

[wolfmanjm]

Please note version 2 is uploaded, I made some pretty basic errors in
version 1 ;)

On Feb 15, 2:44 pm, "wolfmanjm" <wolfma...@gmail.com> wrote:
> As suggested by a number of people I have updated this SCM module to
> use rsync as an option.
> I uploaded to the files section of this group and I updated my Blog
> entry.
>
> The file is now called local_subversion_rsync.rb and the class name
> changed too.
> This should be fully backward compatible too with the previous
> versions and the standard svn scm module.
>

> http://blog.wolfman.com/articles/2006/12/06/a-capistrano-scm-module-f...

[wolfmanjm]

Thanks to a report I fixed a problem where revisions.log was not being
updated.
(I think that is being deprecated anyway :)

This is now fixed and I have removed the older versions of the file,
the current version is
in the files section of this group called
local_subversion_rsync_3.tar.gz and also at my blog site...

http://blog.wolfman.com/articles/2007/02/18/updated-capistrano-local-subversion-and-perforce

This supports all older versions and adds rsync as an option for
actual deployment.

Please report any other problems.

Thanks