Howto generate list of changed files...

[Jay 'Whip' Grizzard <el...@lupine.org>]

Okay, I've been through the book, the list archives, and all of the 'help'
output, and I've yet to be able to figure out a way to do this, so I'm going
to ask and see if I'm overlooking something obvious. The question might not
make much sense if you're only using subversion for source code, but in the
context of revision controlling binary files, I think it makes sense.


I've got a tag in my repository (we'll call it /tags/release1), representing 
  a software release.
I've got a tag in my repository (/tags/release2), representing an 'updated' 
  version of that software release.

Re: Howto generate list of changed files...

[Ben Collins-Sussman <su...@collab.net>]

"Jay 'Whip' Grizzard" <el...@lupine.org> writes:

> Which brings me back to ... any ideas for generating these 'diffs' in a 
> more sane manner? :)

How about 'svn merge --dry-run' ?

For example:

$ cd trunk
$ svn merge --dry-run \
    http://svn.collab.net/repos/svn/tags/0.22.1 \
    http://svn.collab.net/repos/svn/tags/0.22.2

   build.conf
   win-tests.py
   subversion/include/svn_version.h
   subversion/libsvn_subr/getdate.cw
   subversion/libsvn_subr/io.c
   subversion/libsvn_repos/repos.c
   subversion/libsvn_ra_dav/util.c
   build/generator/msvc_dsp.ezt
   build/generator/gen_vcnet_vcproj.py
   build/generator/gen_base.py
   build/generator/gen_win.py
   build/generator/gen_msvc_dsp.py
   tools/cvs2svn/cvs2svn.py
   CHANGES


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Howto generate list of changed files...

[Jay 'Whip' Grizzard <el...@lupine.org>]

> 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.
[snip]

Well, you have good points (and, indeed, I'd already gone through
these myself), but there -are- valid points for wanting what I asked 
about.

The most prominent example: Patches for the Sun packaging/patch system.
Patches are stored as complete copies of just the files to be updated. 
If one wants to use that system (I do), one wants to abide by those rules,
or simply re-ship the package ... but when your package is well over a gig
and your patch is only a few megs, that becomes a much less desirable 
option.

In this particular environment, files getting removed will be the excepttion
rather than the rule (I think it's happened once), and I'm willing to deal 
with that edge case when it happens. And good QA should insure that these 
edge cases don't get missed.


Which brings me back to ... any ideas for generating these 'diffs' in a 
more sane manner? :)

-jay



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Howto generate list of changed files...

[Daniel Patterson <da...@adaptiveinternational.com>]

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