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

RE: Re: What does 'svn diff' do?

From: Terence Crump <TCrump_at_glgroup.com>
Date: 2005-10-14 21:11:17 CEST

How can I get a build of subversion 1.1.4 with _svn in the svn_wc.h file so I can use command line with windows? I have the correct version of tortoise that we use here, it does CHECKOUT using _svn format, but when I try to command line commit, or something to this nature, it doesn't recognize the folder as being a working folder. I will take any build that is compatible with this one as long as it has the _svn in it, ive tried building it over and over, just wont work for me!!!





J. Terence Crump


Release Engineer


Gerson Lehrman Group


850 Third Avenue, 9th Floor New York, NY 10022
Telephone: 212 750 1856 Fax: 212 984 8538


www.glgroup.com www.glgcouncils.com


New York Austin Boston Chicago Los Angeles San Francisco
Washington, DC London Hong Kong Shanghai Sydney


This e-mail message, and any attachments, is intended only for the use of the individual or entity identified in the alias address of this message and may contain information that is confidential, privileged and subject to legal restrictions and penalties regarding its unauthorized disclosure and use. Any unauthorized review, copying, disclosure, use or distribution is strictly prohibited. If you have received this e-mail message in error, please notify the sender immediately by reply e-mail and delete this message, and any attachments, from your system. Thank you.

-----Original Message-----
From: Greg Hudson [mailto:ghudson@MIT.EDU]
Sent: Friday, October 14, 2005 3:06 PM
To: Malcolm Rowe
Cc: dev@subversion.tigris.org
Subject: Re: What does 'svn diff' do?

On Fri, 2005-10-14 at 16:36 +0100, Malcolm Rowe wrote:
> Okay - just so that I understand this: in the case where you have only
> modified existing files, the output of 'svn diff' should be always be
> equivalent to the nave output that GNU diff would produce, given the
> two trees. In all other cases, we will need to choose (or have already
> chosen) between that, and producing 'more useful' output. Is that
> approximately correct?


> So, as a concrete example, does that mean that, if we were to decide
> that file or directory renames would be better reported as no-content
> 'renames' in diff output rather than full-content 'delete/add' pairs,
> we would be happy to make that change by default? [I'm not suggesting
> that this _is_ a change we'd want to make, but if we _did_, could we?]

I'd say so.

> If people are relying on the current behaviour, then it sounds the
> answer to my question above is "no". Is the definition of 'svn diff'
> therefore effectively "whatever we have now"?

"svn diff" should, by default, present tree changes in the most reviewable way possible, because that's how it generally works now and I think people rely on that. That's not the same as saying 'the definition of svn diff is the output svn diff produces'.

> For example, IIRC, issue #2333 basically boils down to the fact that
> repos-repos diffs don't report subtree deletions. The other modes
> (repos->wc, wc->wc) _do_ report such deletions, but since we don't
> have a definition of what 'svn diff' should report, how do we decide
> which, if either, should change?
> Do we really have to do all this on an ad hoc basis?

It's true that "present tree changes in the most reviewable way possible" is a somewhat more squishy definition than "present tree changes in a way that they will be reflected by patch". But I don't think it's the same as deciding everything on an ad hoc basis.

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

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Oct 14 21:12:31 2005

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.