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
problems:
- 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
around).
daniel
---------------------------------------------------------------------
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