Hi Nathan,
I take your point - it probably wouldn't be such a bad thing to package
up the entire revision. My thinking was that I didn't want to re-upload
things that really, really haven't changed - in particular the images
associated with the site. The site I'm currently working on is ~52Mb
with ~6,000 files so without an uber-uplink that's frustrating
(especially the ftp chatter for lots of small files). I could transfer
it to the site compressed (~13Mb) and decompress using a web file
manager but that'd just be another step with another login.
As it stands my recent changed files from the previous revision is ~2Mb
uncompressed and only 25 files. This makes it far more manageable to
distribute and upload.
Cheers,
Scott
Nathan Nobbe wrote:
> 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
> <mailto: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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Jun 29 01:12:11 2007