SVN checkout vs. SVN export

[Wes Gamble]

I'm looking through my new deploy options with Cap 2, and I see the
distinction between a SCM checkout and export. I was unaware of the
export option in SVN.

Is the export just so that you can get a completely clean (e.g. no
embedded SVN folders) set of the current files?

What are the tradeoffs of doing a checkout vs. an export?

Thanks,
Wes

[Jamis Buck]

Yup, the difference is just that with a checkout, you have a working
copy that can be svn up'd, etc. With an export, you get a clean copy
of the code, and none of the subversion metadata, so it can't be used
to svn up or make further changes.

Tradeoffs:

A checkout will be (slightly) larger, and could possibly expose
your .svn directories via HTTP if you don't have the appropriate
rewrite rules to hide them, but it lets you easily deploy simple
changes (template tweaks, CSS tweaks, etc.) by logging in and doing
"svn up". Not a best practice, but sometimes convenience trumps
theoritical purity.

An export will be smaller, and cannot ever expose your .svn metadata
directories, because they don't exist in the export. However, the only
way to deploy changes is to either copy the changes from your local
working copy to the remote servers, or to do a full "cap deploy".

- Jamis

> --~--~---------~--~----~------------~-------~--~----~
> To unsubscribe from this group, send email to capistrano-...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/capistrano
> -~----------~----~----~----~------~----~------~--~---
>

[David Masover]

I have a custom task to do a cached export. That is, there is a shared checkout somewhere, and update_code is a fast "svn update", which then exports to the "release" folder. Basically just a performance hack which is otherwise just an export.

And once it's down to just "cap deploy", I think running an "svn up" command on the remote machine would actually be less convenient. The fact that the deploy is faster (with the cache) helps.

[David Masover]

Sorry, not a custom task, a custom deploy strategy.

[Mislav Marohnić]

On Fri, Mar 14, 2008 at 8:20 PM, David Masover <david....@scribestorm.com> wrote:

I have a custom task to do a cached export. That is, there is a shared checkout somewhere, and update_code is a fast "svn update", which then exports to the "release" folder. Basically just a performance hack which is otherwise just an export.

Hmm, that sounds a lot like this:

  set :deploy_via, :remote_cache

I find it the fastest deploy strategy.

[Ken Collins]

What a coincidence. I just did one of those too :)
I'll post on another topic.

On Mar 14, 4:34 pm, "Mislav Marohnić" <mislav.maroh...@gmail.com>
wrote:

> On Fri, Mar 14, 2008 at 8:20 PM, David Masover <
>

[David Masover]

It's based on that, actually. Depends on it. Sorry I wasn't clearer, didn't mean to take credit for it...

remote_cache doesn't export, it just does a 'cp' command. Mine does an export.