[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Howto generate list of changed files...

From: Daniel Patterson <danpat_at_adaptiveinternational.com>
Date: 2003-05-28 02:10:33 CEST

On Wed, 2003-05-28 at 08:16, Jay 'Whip' Grizzard wrote:
> 2. Use 'svn diff' to generate the list of files that differ, run it through
> some type of script to extract the list of differing filenames from the
> 'diff' output, create the relevant directories, and then 'svn cp' the files
> into place. This is more do-able, but it seems like more work than should
> be needed, especially since subversion lacks the equivilent of 'mkdir -p'

Why not just store the output of "svn diff" and release it as a single
patch file to be re-applied with the GNU "patch" tool? Either that,
or do it the old fashioned way of "svn export tag1" "svn export tag2"
"diff -u tag1 tag2 > tag1-to-tag2.patch". This is the approach the
linux kernel takes and has worked flawlessly for quite some time.

Just releasing a zip of "changed and new files" has the following

  - Things don't get deleted, so over time, you'll accumlate crud
  - Changed files are overwritten. With patch, it'll at least have a go
    at merging. It'll let you know about conflicts to, which should
    be properly resolved.

We used to take this approach to releasing patches to customers.
However, the mess it created ended up biting us too often, so now, we
release a "full" version, and a GNU patch that turns the old into the
new (if there are customisations). Simply releasing the changed files
is *really* prone to accumlated errors, and you end up with the customer
with a configuration management that doesn't match anything you ever
gave them which means it's really hard to debug, you're not sure why
they're experiencing problems that you've already fixed, and they can't
tell you exactly what version they've got because they're getting
conflicting information from looking at the files (old ones still lying


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed May 28 02:11:29 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.