Why does capistrano keep multiple checkouts?

[tim]

Hey guys.

Just out of curiosity...

I was wondering why capistrano keeps past checkouts instead of using
the version control mechanism itself.

In other words why not a "git reset --hard revno" or something
similar?

Cheers.

[Wes Gamble]

Tim,

I think it's probably just historical - git wasn't in widespread use at the time capistrano was initially developed (as "switchtower").

This is an interesting idea, and would save quite a bit on filesystem space.

Wes

[Rob Biedenharn]

You'd loose the constant-time rollback of swapping the symlink back.

-Rob

--
* You received this message because you are subscribed to the Google Groups "Capistrano" group.
* To post to this group, send email to capis...@googlegroups.com
* To unsubscribe from this group, send email to capistrano+...@googlegroups.com For more options, visit this group at http://groups.google.com/group/capistrano?hl=en

[Donovan Bray]

Because a deploy is rarely only what's under version control. Think about generated config files, generated assets, bundler invocations.

The timestamp feature is so that you can rollback a bad deploy in its totality (with the caveat of DDL changes to databases)

Github has a recipe for converting to a git-pull single release directory if that suits you, search their blog.

[Lee Hambley]

As Donovan said, a deploy isn't only what's under VC *typically*. That's not always true, and Capistrano suffers from catering to the lowest common denominator, which is the `copy` strategy, Sure there's smarter things that would be possible with hardlinks, and really making use of Git. But there are such tools (Heroku push deploy, vlad, Github's post-receive deploy hook, etc).

Another large part is also what Donovan mentioned, being able to reliably, and easily roll-back.

Capistrano is still the everyman tool, which people can bend to their will, as such it will never be the finest example of an intelligent deploy using Git; if you're not generating configs, sharing resources between deploys, relying on rollbacks, callbacks, migrations, etc - you might be better served by a simpler (less wasteful) tool.

-- Lee