I disagree, why else would you have an scm option to begin with? The whole advantage of using it for a pull scenario is that you can just "svn up" the diff.
A crude way of doing it would be to keep a svn/git copy in your prod server, run a update/pull and from the log/output figure out what files changed and copy only those files to the right places. Hope it helps,
AEM
On Sun, Jun 15, 2008 at 12:43 PM, Anthony Ettinger <ettin...@gmail.com> wrote:
> Using :export takes quite a long time, even for editing one file.
> Is there a way to only push the difference, and not the entire trunk?
> > Using :export takes quite a long time, even for editing one file.
> > Is there a way to only push the difference, and not the entire trunk?
> Using Capistrano 2, you can use the set :deploy_via, :remote_cache > variable to have it keep a cached copy and just do an update and copy > from that.
The problem is that there is not a one to one match with the
deployed application and the content of the SCM. Common deployment
recipes involve symlinking, generating a version file, etc. Also,
letting the .svn (in the Subversion case) files in releases/
<timestamp> is a security risk, most people sets capistrano to do a
checkout losing the version metadata.
I understand your point, actually Bazaar has this concept:
If this were going to be implemented the first thing to solve is
how to manage the releases/<timestamp> folders, maybe copying the the
previous release and generating the delta against the new version. I
need to keep the ability to do rollbacks.
--
Anibal
On Jun 17, 12:41 pm, "Anthony Ettinger" <ettin...@gmail.com> wrote:
> I disagree, why else would you have an scm option to begin with?
> The whole advantage of using it for a pull scenario is that you can
> just "svn up" the diff.
> On Mon, Jun 16, 2008 at 4:19 AM, Aníbal Rojas <anibalro...@gmail.com> wrote:
> > As far as I know there is no support for a "diferential" or "delta"
> > deploymet.
li...@blueboxgrp.com> wrote:
> > Using :export takes quite a long time, even for editing one file.
> > Is there a way to only push the difference, and not the entire trunk?
> Using Capistrano 2, you can use the set :deploy_via, :remote_cache
> variable to have it keep a cached copy and just do an update and copy
> from that.
On Tue, Jun 17, 2008 at 3:57 AM, Aníbal Rojas <anibalro...@gmail.com> wrote:
> Anthony,
> The problem is that there is not a one to one match with the > deployed application and the content of the SCM. Common deployment > recipes involve symlinking, generating a version file, etc. Also, > letting the .svn (in the Subversion case) files in releases/ > <timestamp> is a security risk, most people sets capistrano to do a > checkout losing the version metadata.
> I understand your point, actually Bazaar has this concept:
> If this were going to be implemented the first thing to solve is > how to manage the releases/<timestamp> folders, maybe copying the the > previous release and generating the delta against the new version. I > need to keep the ability to do rollbacks.
> -- > Anibal
> On Jun 17, 12:41 pm, "Anthony Ettinger" <ettin...@gmail.com> wrote: >> I disagree, why else would you have an scm option to begin with? >> The whole advantage of using it for a pull scenario is that you can >> just "svn up" the diff.
>> On Mon, Jun 16, 2008 at 4:19 AM, Aníbal Rojas <anibalro...@gmail.com> wrote:
>> > As far as I know there is no support for a "diferential" or "delta" >> > deploymet.
> There's a program called rsnapshot used for creating hourly backups, > similar pattern may be applicable to deployments.
> I'm currently using the :export option, which makes a duplicate of the > entire tree (even if only 1 file has changed).
> The rsnapshot perl script I'm referring to uses rsync to provide the > delta and only copies files that have been changed, added, or removed.
> It makes a hardlink of all existing files that have not been modified > (saving on disk space) to create the rest of the un-modified tree.
> The advantage is that a deploy could take a few seconds vs. several > minutes, and save on disk space.
> On Tue, Jun 17, 2008 at 3:57 AM, Aníbal Rojas > <anibalro...@gmail.com> wrote:
>> Anthony,
>> The problem is that there is not a one to one match with the >> deployed application and the content of the SCM. Common deployment >> recipes involve symlinking, generating a version file, etc. Also, >> letting the .svn (in the Subversion case) files in releases/ >> <timestamp> is a security risk, most people sets capistrano to do a >> checkout losing the version metadata.
>> I understand your point, actually Bazaar has this concept:
>> If this were going to be implemented the first thing to solve is >> how to manage the releases/<timestamp> folders, maybe copying the the >> previous release and generating the delta against the new version. I >> need to keep the ability to do rollbacks.
>> -- >> Anibal
>> On Jun 17, 12:41 pm, "Anthony Ettinger" <ettin...@gmail.com> wrote: >>> I disagree, why else would you have an scm option to begin with? >>> The whole advantage of using it for a pull scenario is that you can >>> just "svn up" the diff.
>>> On Mon, Jun 16, 2008 at 4:19 AM, Aníbal Rojas >>> <anibalro...@gmail.com> wrote:
>>>> As far as I know there is no support for a "diferential" or "delta" >>>> deploymet.
