svn diff output

Jack recently gave a suggestion for how to fix a problem he has but I
think it's the wrong way to go. Not because I think he has a bad
demand, but because I think it fails to meet a lot of other needs and
seems like a kludge.

Part of the problem as he observes is that different people have
different expectations of what they want from svn diff. Some people
want something that they can use to view their changes. Others want
output that is usable to feed into patch on someone elses computer.

Both of these are reasonable uses of svn diff.

Ultimately though we have the following additional problem. svn diff's
output does not produce output that is usable by patch to reconstruct
the exact operations done. You can't make a set of changes, decide not
to commit at that time, produce a svn diff, and then throw away the
working copy and then expect that the svn diff output will be usable to
reproduce the state of that working copy.

I remember talking with Karl about this and he didn't think it was this
projects job to come up with a format that achieves that. But I think
it is. Here's why:

a) First of all we're an open source project. We receive submissions
from a lot of people who don't have direct commit access. Patches are
a key method of our operation. However, people can't submit patches
that copy files, or apply modifications to properties. Yet these are
important parts of our functionality.

For example. We have people translating the book now. They've
submitted patches against the English version of the book. However,
their patches don't represent a copy from the version of the book they
are working against. The person commiting their changes must know what
rev they were working against, copy the English book at that rev to the
new translation location, and then apply the patch. The patch comments
help with this, but I don't think it should be necessary for them to do
this by hand.

b) If not us then who? If we won't create a patch format that supports
describing all the changes our repositories can version then exaction
who will? Why would someone set out to do this?

While the unified patch format (which only supports file contents) is
generally applicable to all SCM tools. Something that does more than it
can't really be that way. We have properties and other versioned
meta-data. We version trees. We use global revision numbers. I'm not
sure it makes sense or is possible to have a general purpose format that
can describe everything we support.

But I do believe it is desireable for us to have a format to support all
of our features.

So this is my alternative proposal to the problems we face.

1) Develop a new format that supports our features:

  * Copies
  * Deletes
  * Moves (We don't support these directly now but we intend to in the
           future, so we should allow for this)
  * Add without history
  * Property Modifications
  * File content modifications

  Make svn diff output this format if you pass it a flag. I'm not clear
  on what this flag should be called. But I'm thinking something along
  the lines of how cvs handled unified diff.

2) Make svn diff without this flag produce output that is usable to
   reproduce the file changes with the standard patch command. I.E.
   svn diff would essentially default to --show-copies in Jack's
   proposal.

3) At 2.0.0 change the default to our diff format and require --unified
   or -u to get the current output. If we don't develop this new format
   before 2.0.0 then so be it.

How does this resolve Jack's problems? Once the new format is the
default the output will be in the context of just using SVN. I.E.
copies will show as just a succinct representation of a copy. It
wouldn't include the content of the file you copied. It would be a
description of what SVN would do to the repo if you committed right now.
THis is likely what most of our users want most of the time.

However, somtimes our users have to interact with people using other SCM
systems or no SCM system and just patch. They then want a diff output
that is verbose enough to apply the changes they made.

If people still want a unified diff option that ignores copied files,
then we could I suppose add an option for that. But I suspect this
covers the real use cases people have. People that don't want to see
copies are going to be content with using our format and that format can
serve the double purpose of being supported by a svn patch command that
reads it and applies the changes to the working copy (or potentially
directly to the repo without a wc).

Thoughts?

-- 
Ben Reser <ben@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org