You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by kf...@collab.net on 2005/10/06 20:48:19 UTC
Command-line output changes in 1.3
Ben Collins-Sussman has once again volunteered (and this time it
really is volunteering!) to write the CHANGES file for 1.3.
He'll probably do a first cut and then seek review. But I thought I'd
ask one question now, because I'm writing svn_1.3_releasenotes.html,
which needs to document major changes like the following:
Have there been any command-line output changes in 1.3 (since 1.2, I
mean)? That includes both changes to existing default output, and the
addition of new options which can cause new kinds of output.
-Karl
--
www.collab.net <> CollabNet | Distributed Development On Demand
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Command-line output changes in 1.3
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
On Wed, 12 Oct 2005, Julian Foad wrote:
> Peter N. Lundblad wrote:
> >
> >>Have there been any command-line output changes in 1.3 (since 1.2
> >
> > We have r14855, which fixes issue #2233.
>
> Note that it doesn't do quite what Peter's plan in the issue says; that
> confused me for a while.
>
It was discussed on the list after I annotated the issue while grabbing
it. I'm not very good at putting links to further discussions into the
tracker:-(
> This is relevant to the present discussion about what "svn diff" ought to be
> doing <http://svn.haxx.se/dev/archive-2005-10/0359.shtml>. We should consider
> whether the same interface and functionality is wanted for "svn diff".
>
Yes, thats why I pointed it out in that thread somewhere:-)
>
> > It makes svnlook print always diffs for added files by default.
>
> That is, without any flags, it makes "svnlook diff" print an
> all-lines-added diff for an added or copied (added with history) file.
> Previously, it had been inconsistent.
>
>
> > It also adds --diff-copy-from to print diffs against copyfrom source instead
> > of the empty stream.
>
Yep.
> I assume that for a copied but unmodified file this will print a header
> indicating that it is copied, but obviously no diff of the contents.
>
Yep.
> I think we need a bit more documentation than the current "--help" output:
>
> > diff: usage: svnlook diff REPOS_PATH
> >
> > Print GNU-style diffs of changed files and properties.
> >
> > [...]
> > --no-diff-deleted : do not print differences for deleted files
> > --no-diff-added : do not print differences for added files
> > --diff-copy-from : print differences against the copy source
>
Most svnlook help strings are a bit terse, so yes, I agree. But a detailed
description might be better off in the book or something.
Regards,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Command-line output changes in 1.3
Posted by Julian Foad <ju...@btopenworld.com>.
Peter N. Lundblad wrote:
>
>>Have there been any command-line output changes in 1.3 (since 1.2
>
> We have r14855, which fixes issue #2233.
Note that it doesn't do quite what Peter's plan in the issue says; that
confused me for a while.
This is relevant to the present discussion about what "svn diff" ought to be
doing <http://svn.haxx.se/dev/archive-2005-10/0359.shtml>. We should consider
whether the same interface and functionality is wanted for "svn diff".
> It makes svnlook print always diffs for added files by default.
That is, without any flags, it makes "svnlook diff" print an all-lines-added
diff for an added or copied (added with history) file. Previously, it had been
inconsistent.
> It also adds --diff-copy-from to print diffs against copyfrom source instead
> of the empty stream.
I assume that for a copied but unmodified file this will print a header
indicating that it is copied, but obviously no diff of the contents.
I think we need a bit more documentation than the current "--help" output:
> diff: usage: svnlook diff REPOS_PATH
>
> Print GNU-style diffs of changed files and properties.
>
> [...]
> --no-diff-deleted : do not print differences for deleted files
> --no-diff-added : do not print differences for added files
> --diff-copy-from : print differences against the copy source
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Command-line output changes in 1.3
Posted by kf...@collab.net.
"Peter N. Lundblad" <pe...@famlundblad.se> writes:
> We have r14855, which fixes issue #2233. It makes svnlook print
> always diffs for
> added files by default. It
> also adds --diff-copy-from to print diffs against copyfrom source instead
> of the empty stream. And headers are changed when diffing against the
> empty file to be consistent with svn diff, that is print revision 0
> instead of the copyfrom revision.
>
> r14621 makes merge add conflict markers in the encoding of the user's
> locale. (Not sure if this classifies as cmdline client *output*).
>
> r14557 fixes #1533, printing diff output in the native encoding instead of
> UTF8.
Thanks, Peter. I incorporated these in r16675.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Command-line output changes in 1.3
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
On Thu, 6 Oct 2005 kfogel@collab.net wrote:
> Have there been any command-line output changes in 1.3 (since 1.2, I
> mean)? That includes both changes to existing default output, and the
> addition of new options which can cause new kinds of output.
>
We have r14855, which fixes issue #2233. It makes svnlook print
always diffs for
added files by default. It
also adds --diff-copy-from to print diffs against copyfrom source instead
of the empty stream. And headers are changed when diffing against the
empty file to be consistent with svn diff, that is print revision 0
instead of the copyfrom revision.
r14621 makes merge add conflict markers in the encoding of the user's
locale. (Not sure if this classifies as cmdline client *output*).
r14557 fixes #1533, printing diff output in the native encoding instead of
UTF8.
Regards,
//Peter
Regards,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Command-line output changes in 1.3
Posted by Daniel Rall <dl...@finemaltcoding.com>.
On Wed, 12 Oct 2005, kfogel@collab.net wrote:
> Daniel Rall <dl...@finemaltcoding.com> writes:
> > I had a rather strong urge to change 'svn status -u -v' to show the
> > repository state rather than the working copy state (as it does now),
> > but did not make the trivial (from a code perspective) change in 1.3,
> > due to concerns about backwards compatibility. I propose we do consider
> > where such a change belongs: 1.4, 2.0, etc.
>
> I meant to ask, what exactly does this change mean?
'svn help st' shows:
...
Remaining fields are variable width and delimited by spaces:
The working revision (with -u or -v)
The last committed revision and last committed author (with -v)
The working copy path is always the final field, so it can
include spaces.
...
svn status --show-updates --verbose wc
M 965 938 kfogel wc/bar.c
* 965 922 sussman wc/foo.c
A + 965 687 joe wc/qax.c
965 687 joe wc/zig.c
Status against revision: 981
...
Currently, all of the information except for the * is read from the entries
file. As the --show-updates (-u) argument triggers repository access, most
people I've surveyed have been surprised that the "last committed revision"
and "last commited author" information is not any more-up-to-date info from
the repository, but still what's read from the entries file.
Considering the slow-down you get from --show-updates contacting the
repository, the fact that the delta editor always sends back any new state
from the repository, and the fact that we are now finally grabbing this state
(instead of dropping it on the floor like we used to do), actually making use
of that information for 'svn st -uv' would be a great improvement in
behavior.
Though a trivial code change localized to only a couple of files, this is a
rather noticable departure from the current behavior of 'status'.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Command-line output changes in 1.3
Posted by kf...@collab.net.
Daniel Rall <dl...@finemaltcoding.com> writes:
> I had a rather strong urge to change 'svn status -u -v' to show the
> repository state rather than the working copy state (as it does now),
> but did not make the trivial (from a code perspective) change in 1.3,
> due to concerns about backwards compatibility. I propose we do consider
> where such a change belongs: 1.4, 2.0, etc.
I meant to ask, what exactly does this change mean?
-Karl
--
www.collab.net <> CollabNet | Distributed Development On Demand
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Command-line output changes in 1.3
Posted by Daniel Rall <dl...@finemaltcoding.com>.
On Thu, 06 Oct 2005, kfogel@collab.net wrote:
...
> Have there been any command-line output changes in 1.3 (since 1.2, I
> mean)? That includes both changes to existing default output, and the
> addition of new options which can cause new kinds of output.
I had a rather strong urge to change 'svn status -u -v' to show the
repository state rather than the working copy state (as it does now),
but did not make the trivial (from a code perspective) change in 1.3,
due to concerns about backwards compatibility. I propose we do consider
where such a change belongs: 1.4, 2.0, etc.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org