Scott,
I was suggesting to 'lug around the whole revision' as i dont see that as a
large issue.
i tarred up nearly 200,000 lines of php source this morning and its only
about 15 MB using
gzip compression.
On the sdlc thing, i was suggesting that creating tags and 'lugging them
around' is the svn way
but thats based on my somewhat moderate experience w/ svn thus far. from my
perspective just
tagging a revision and pushing it out to the servers is the most
straightforward approach.
and you can definitely push that over ftp.
the only reason i can see for pushing out the differences and patching the
source is if you have slim
transfer requirements to the servers themselves or a ton of source to push;
which maybe you do, i
dont know.
patching live code against differences is cool and all, but i thought you
were looking for something simple.
-nathan
On 6/28/07, Scott Pederick <scott@solidstrategies.com.au> wrote:
>
> Hi Nathan,
> > just guessing a bit; as i havent used this myself; but isnt this what
> > patch <http://en.wikipedia.org/wiki/Patch_%28Unix%29> is for?
> > basically the flow here is to diff the to repositories; dump the diff
> > of each file in the repo to a diff file.
> > then recursively apply the diff files to the target source base using
> > patch.
> > you would still need to handle adding new files and removing deleted
> > files though.
> The problem is I can't use patch - the app is stored as php source and
> is only accessible via ftp. The only way to upload it is to upload each
> of the files that have changed. Rather than having to lug around the
> entire revision, I want to be able to package up just the changed files
> in an archive. You this extract the archive, upload it over the top of
> the existing source since the directory structure is maintained and the
> web app is patched.
> > in order to get a listing of the files that have changed between 2
> > components of the repository (typically a development branch and the
> > trunk)
> > svn diff -x -w svn+ssh://user@repohost/trunk
> > svn+ssh://user@localhost/branch-wc | grep '+++'
> > svn diff -x -w svn+ssh://suer@repohost/trunk
> > svn+ssh://user@localhost/branch-wc | grep '\-\-\-'
> >
> > so, in my mind i would start out by using those commands to generate a
> > list of files then iterate over the list producing the diff files.
> > note here, im assuming the diff output from svn is compatible w/ gnu
> > diff (because thats what patch takes as input).
> >
> > you will have to have some client-side script to handle the merging;
> > no matter what the implementation, so
> > if you are deploying the php to windows and unix(ish) machines you
> > will likely have to maintain separate scripts for both platforms.
> >
> > why not just use a tagging approach and push out revisions of the
> > source? i think this would be a more direct solution and very easy to
> > implement.
> > also, i think tagging is more in tune w/ the svn way of facilitating
> > sdlc (imho).
> Not sure what you mean by this but that probably has more to do with my
> understanding of svn. Even if the release is tagged, it doesn't make it
> any easier to get the list of changed files but just a different
> checkpoint to generate a "patch" (ie. archive of changed files) against.
>
> Sorry if I haven't understood entirely what you meant but the main
> problem is that I only have ftp access to these shared hosting
> environments. Thanks for the reply.
>
> Cheers,
>
> Scott
>
Received on Thu Jun 28 15:36:49 2007