You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Karl Fogel <kf...@newton.ch.collab.net> on 2001/12/17 23:45:22 UTC
`svn diff' progress
philip@tigris.org writes:
> Log:
> Provides 'svn diff -r REV' functionality to compare the working copy
> against a given revision in the repository. The existing 'svn diff'
> behaviour is unchanged.
Whoo hoo!!! Bravo, Philip, this is great.
Diff is almost done now, though still some functionality needed:
$ svn diff -r 659 subversion/clients/cmdline/main.c
Index: subversion/clients/cmdline/main.c
===================================================================
--- subversion/clients/cmdline/main.c
+++ subversion/clients/cmdline/main.c Mon Dec 17 18:32:00 2001
@@ -93,8 +93,9 @@
{ "rm", TRUE, NULL, NULL },
{ "diff", FALSE, svn_cl__diff,
- "Display local file changes as contextual diffs.\n"
- "usage: diff [TARGETS]\n" },
+ "Display local changes in the working copy, or changes between the\n"
+ "working copy and the repository if a revision is given.\n"
+ "usage: diff [-r REV] [TARGETS]\n" },
{ "di", TRUE, NULL, NULL },
{ "help", FALSE, svn_cl__help,
That worked. Diff with no args shows no differences, which is right
because I have an up-to-date working copy:
$ svn diff subversion/clients/cmdline/main.c
$
What about diffing current revision of a file against same path in a
revision where it doesn't exist:
$ svn diff -r 659 subversion/libsvn_wc/diff.c
apr_error: #20014, src_err 0 : <Error string not specified yet>
The REPORT status was 500, but expected 200.
$
Okay, that's probably related to issue #581, see
http://subversion.tigris.org/issues/show_bug.cgi?id=581 for details.
Let's try not specifying any target files:
$ svn diff -r 659
[out put looks great, except for...]
Index: ./subversion/libsvn_wc/diff.c
===================================================================
/usr/bin/diff: ./subversion/libsvn_wc/.svn/empty-file: No such file \
or directory
[the output for file that weren't just added is fine, though]
Looks like older working copies won't handle this robustly. Can you
put some run-time upgrade code in there... (Or better yet, find a way
to do it without using `empty-file'; Mike Pilato thinks there is a
way, maybe he can comment more...?)
Then I tried diffing two arbitrary revisions:
$ svn diff -r 640:660 subversion/clients/cmdline/main.c
svn_error: #21012 : <Trying to use an unsupported feature>
diff only supports a single revision
$
Ah,, okay, we don't support that yet. :-) (Is that next on your list,
Philip?) Same strategy, I guess: just download both files and diff
them client side, the downloads can be diffs against the working copy
revision, and/or one of the downloads can be a diff against the other
download, whatever works best...
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: `svn diff' progress
Posted by Mark Benedetto King <bk...@answerfriend.com>.
On Tue, Dec 18, 2001 at 03:31:28PM -0800, Greg Stein wrote:
> On Tue, Dec 18, 2001 at 06:10:27PM -0500, Mark Benedetto King wrote:
> >...
> > Why not just have the diff crawler download both revisions, diff them,
> > and delete them? Am I missing something?
>
> Crawl over what? I maintain that diff between two revs can't refer to the
> working copy.
You're absolutely right. I don't know the lingo for "walk the remote
repository hierarchy an entry at a time".
>
> > WRT Greg Stein's suggestions about showing the individual changes:
> > nice feature, but I think we need cumulative diffs as well.
>
> Eh? Mine is cumulative? It can show diffs between any two revisions, and it
> can do it for a whole tree of changes. Maybe I'm not understanding something
> you're saying?
>
No, I misinterpreted what you meant when you said
"* for each change, display that change"
You meant "the cummulative changes between r1 and r2". I interpreted
that as "the individual deltas".
I like your idea much better now that I understand it. :-)
--ben
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: `svn diff' progress
Posted by Colin Putney <cp...@whistler.com>.
On Thursday, December 20, 2001, at 08:36 AM, Karl Fogel wrote:
> Colin et al,
>
> The sense in which cases (2) and (3) below involve the working copy is
> only this: that knowing the client-side revisions of various files can
> result in a more efficient (smaller) download from the server, because
> the server can send *both* files to be diffed as svndiffs against
> whatever's in the working copy.
>
> Completely agree that the working copy is not formally relevant,
> except as a provider of metadata and svndiff bases.
>
> Anyway, this so-called "efficiency" may or may not be worth the
> overhead; after all, in the case of two arbitrary revisions, there is
> some effort to be spent merely in determining whether or not sending
> the fulltexts would be more efficient anyway. :-)
Not so! Your comment above is true for case 2, in which a URL is diffed
against a URL - a working copy isn't even required for this operation.
But case 3 is different - let me give a more detailed example.
Imagine that I have a simple probject with experimental branch of
development. So my repository is laid out like this.
%find . -t file
./trunk/foo.c
./trunk/bardir/bar.c
./trunk/bardir/baz.c
./branches/experimental/foo.c
./branches/experimental/bardir/bar.c
./branches/experimental/bardir/baz.c
Now I do this:
svn co http:/host/repos/branches/experimental
svn diff -r 600:700 .
Clearly this cannot occur without a working copy. The client will have
to crawl the working copy to figure out the urls of the files it needs
to fetch and diff.
Colin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: `svn diff' progress
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Colin et al,
The sense in which cases (2) and (3) below involve the working copy is
only this: that knowing the client-side revisions of various files can
result in a more efficient (smaller) download from the server, because
the server can send *both* files to be diffed as svndiffs against
whatever's in the working copy.
Completely agree that the working copy is not formally relevant,
except as a provider of metadata and svndiff bases.
Anyway, this so-called "efficiency" may or may not be worth the
overhead; after all, in the case of two arbitrary revisions, there is
some effort to be spent merely in determining whether or not sending
the fulltexts would be more efficient anyway. :-)
-K
Colin Putney <cp...@whistler.com> writes:
> 2) Comparing a URL with a URL.
>
> In this case, the working copy should not be involved, since both
> files are remote. But the diff still has to happen in the client (to
> support plugable diff and merge tools, and to keep the processing load
> off the server) so each pair of files would have to be downloaded to a
> temporary work area before diffing. Examples:
>
> svn diff -r REV1 http://host/repos/dir/foo.c -r REV2
> http://host/repos/dir2/foo.c
> svn diff -r REV1:REV2 http://host/repos/dir/foo.c
>
> 3) Comparing different revisions of a file or directory in the working
> copy.
>
> This case is a bit tricky. The working copy doesn't supply content for
> diffing, but it *does* need to be examined to determine what files in
> the repository need to be compared. In the case of comparing
> directories, the tree below that directory in the working copy would
> have to be crawled. Examples:
>
> svn diff -r REV1:REV2 foo.c
> svn diff http://host/respos/branch/dir/ -r REV dir
>
> I'm not familar enough with the code to suggest an approach, but it
> would have to handle all three of these cases.
>
> Cheers,
>
> Colin
>
>
>
> ---------------------------------------------------------------------
> 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
Re: `svn diff' progress
Posted by Colin Putney <cp...@whistler.com>.
On Tuesday, December 18, 2001, at 03:31 PM, Greg Stein wrote:
> On Tue, Dec 18, 2001 at 06:10:27PM -0500, Mark Benedetto King wrote:
>> ...
>> Why not just have the diff crawler download both revisions, diff them,
>> and delete them? Am I missing something?
>
> Crawl over what? I maintain that diff between two revs can't refer to
> the
> working copy.
I'm a little confused about this as well. There are a few separate cases
here. Assume that foo.c is a versioned file in the current directory,
which is part of a working copy. I also assume that a diff is a straight
comparison between two files - no three-way diffs, or comparisons
between a diff and a file.
1) Comparing a file or directory in the working copy with a URL.
The working copy has to be crawled to find out which files need to be
compared with some revision of that file in the repository. Examples:
svn diff -r REV foo.c
svn diff http://host/respos/dir/foo.c foo.c
2) Comparing a URL with a URL.
In this case, the working copy should not be involved, since both files
are remote. But the diff still has to happen in the client (to support
plugable diff and merge tools, and to keep the processing load off the
server) so each pair of files would have to be downloaded to a temporary
work area before diffing. Examples:
svn diff -r REV1 http://host/repos/dir/foo.c -r REV2
http://host/repos/dir2/foo.c
svn diff -r REV1:REV2 http://host/repos/dir/foo.c
3) Comparing different revisions of a file or directory in the working
copy.
This case is a bit tricky. The working copy doesn't supply content for
diffing, but it *does* need to be examined to determine what files in
the repository need to be compared. In the case of comparing
directories, the tree below that directory in the working copy would
have to be crawled. Examples:
svn diff -r REV1:REV2 foo.c
svn diff http://host/respos/branch/dir/ -r REV dir
I'm not familar enough with the code to suggest an approach, but it
would have to handle all three of these cases.
Cheers,
Colin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: `svn diff' progress
Posted by Greg Stein <gs...@lyra.org>.
On Tue, Dec 18, 2001 at 06:10:27PM -0500, Mark Benedetto King wrote:
>...
> Why not just have the diff crawler download both revisions, diff them,
> and delete them? Am I missing something?
Crawl over what? I maintain that diff between two revs can't refer to the
working copy.
> WRT Greg Stein's suggestions about showing the individual changes:
> nice feature, but I think we need cumulative diffs as well.
Eh? Mine is cumulative? It can show diffs between any two revisions, and it
can do it for a whole tree of changes. Maybe I'm not understanding something
you're saying?
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: `svn diff' progress
Posted by Mark Benedetto King <bk...@answerfriend.com>.
On Tue, Dec 18, 2001 at 04:57:14PM -0600, Karl Fogel wrote:
> Mark Benedetto King <bk...@answerfriend.com> writes:
> > Won't this require twice the total repository size in temporary space
> > if you do a diff starting from the root? That seems like a lot to me.
>
> Twice the total size of a single repository revision tree, yes.
>
You're pretty good at reading what I mean instead of what I write. :-)
> If we wanted to save the space, we could set up a skeletal tree with
> placeholders for files, then get the data from the server at each
> position in the tree? Or have diff run on a node-by-node basis on the
> server side? (Ick, that centralizes the computation load at the
> server, which is bad. Clients should be running diff.)
Why not just have the diff crawler download both revisions, diff them,
and delete them? Am I missing something?
WRT Greg Stein's suggestions about showing the individual changes:
nice feature, but I think we need cumulative diffs as well.
--ben
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: `svn diff' progress
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Mark Benedetto King <bk...@answerfriend.com> writes:
> Won't this require twice the total repository size in temporary space
> if you do a diff starting from the root? That seems like a lot to me.
Twice the total size of a single repository revision tree, yes.
If we wanted to save the space, we could set up a skeletal tree with
placeholders for files, then get the data from the server at each
position in the tree? Or have diff run on a node-by-node basis on the
server side? (Ick, that centralizes the computation load at the
server, which is bad. Clients should be running diff.)
Philip, thoughts?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: `svn diff' progress
Posted by Mark Benedetto King <bk...@answerfriend.com>.
Philip Martin <ph...@codematters.co.uk> writes:
> The alternative is that the first crawler runs over the working copy,
> and the editor builds a temporary working copy. The second crawler
> then runs over this new working copy and a second editor produces the
> required diffs. Now the first crawler/editor is very like the current
> update, and the second is very like the current diff, so I can see how
> this would work. Lots of lovely code reuse into the bargain. There is
> the overhead of constructing a complete working copy, but we need to
> store the hierarchy information somewhere and a working copy is
> probably the simplest way.
>
> In fact writing this has lead me to conclude that the second approach
> is the one to take, having previously been assuming that the first
> would be the one!
Won't this require twice the total repository size in temporary space
if you do a diff starting from the root? That seems like a lot to me.
--ben
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: `svn diff' progress
Posted by Ben Collins-Sussman <su...@collab.net>.
cmpilato@collab.net writes:
> Philip Martin <ph...@codematters.co.uk> writes:
>
> > It would be better to have a platform independent interface to a
> > "temporary area". Something that would allow one to create a temporary
> > directory with some sort of random name. An addition to apr perhaps?
>
> Yep. This would be better. In fact, there is an issue logged already
> against svnlook that sez it should also be using such a "temporary
> area" once APR exposes such a thing.
FWIW, libsvn_client populates a vtable of callbacks for the RA layer
to use. One of these callbacks is a function for creating a temporary
file within the working copy admin area.
The callback used is a public libsvn_wc function:
/* Create a unique temporary file in administrative tmp/ area of
directory PATH. Return a handle in *FP.
The flags will be APR_WRITE | APR_CREATE | APR_EXCL | APR_DELONCLOSE.
This means that as soon as FP is closed, the tmp file will vanish. */
svn_error_t *
svn_wc_create_tmp_file (apr_file_t **fp,
svn_stringbuf_t *path,
apr_pool_t *pool);
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: `svn diff' progress
Posted by cm...@collab.net.
Philip Martin <ph...@codematters.co.uk> writes:
> It would be better to have a platform independent interface to a
> "temporary area". Something that would allow one to create a temporary
> directory with some sort of random name. An addition to apr perhaps?
Yep. This would be better. In fact, there is an issue logged already
against svnlook that sez it should also be using such a "temporary
area" once APR exposes such a thing.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: OS specific temp area
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
"Bill Tutt" <ra...@lyra.org> writes:
> For this simple of an interface, I'd be willing to write the Win32 part
> of the APR patch.
Great, thanks!
Of course, work on "svn diff -r N:M" doesn't have to wait on this.
The majority of the new code won't be affected, and anyway we can just
use .svn/tmp or whatever until then...
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: OS specific temp area
Posted by Bill Tutt <ra...@lyra.org>.
For this simple of an interface, I'd be willing to write the Win32 part
of the APR patch.
FYI,
Bill
--
Bunnies aren't just cute like everybody supposes.
They got their hoppy legs and twitchy little noses.
And what's with all the carrots,
What do they need such good eyesight for anyway?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: `svn diff' progress
Posted by Philip Martin <ph...@codematters.co.uk>.
Karl Fogel <kf...@newton.ch.collab.net> writes:
> Philip Martin <ph...@codematters.co.uk> writes:
> > The alternative is that the first crawler runs over the working copy,
> > and the editor builds a temporary working copy. The second crawler
> > then runs over this new working copy and a second editor produces the
> > required diffs. Now the first crawler/editor is very like the current
> > update, and the second is very like the current diff, so I can see how
> > this would work. Lots of lovely code reuse into the bargain. There is
> > the overhead of constructing a complete working copy, but we need to
> > store the hierarchy information somewhere and a working copy is
> > probably the simplest way.
> >
> > In fact writing this has lead me to conclude that the second approach
> > is the one to take, having previously been assuming that the first
> > would be the one!
>
> :-) Hmmm...
>
> Where on disk are these temporary working copies going to be created?
Good question. The current diff editor only ever has a single
temporary file at any one time, so it just uses .svn/tmp. This is
probably where the working copy would go in the absence of any other
choice.
It would be better to have a platform independent interface to a
"temporary area". Something that would allow one to create a temporary
directory with some sort of random name. An addition to apr perhaps?
Can we compare two repository revisions without creating some sort of
hierarchy? I don't really see a way to do that. The scheme above only
requires one temporary working copy, not one for each revision.
--
Philip
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: `svn diff' progress
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Philip Martin <ph...@codematters.co.uk> writes:
> The alternative is that the first crawler runs over the working copy,
> and the editor builds a temporary working copy. The second crawler
> then runs over this new working copy and a second editor produces the
> required diffs. Now the first crawler/editor is very like the current
> update, and the second is very like the current diff, so I can see how
> this would work. Lots of lovely code reuse into the bargain. There is
> the overhead of constructing a complete working copy, but we need to
> store the hierarchy information somewhere and a working copy is
> probably the simplest way.
>
> In fact writing this has lead me to conclude that the second approach
> is the one to take, having previously been assuming that the first
> would be the one!
:-) Hmmm...
Where on disk are these temporary working copies going to be created?
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: `svn diff' progress
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Philip, are there any uncovered cases remaining for "svn diff"?
I just annotated
http://subversion.tigris.org/issues/show_bug.cgi?id=422
with the same question, feel free to answer it there. :-)
Thanks,
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: `svn diff' progress
Posted by Philip Martin <ph...@codematters.co.uk>.
Greg Stein <gs...@lyra.org> writes:
> How about a third:
>
> * ask the server for differences between rev1 and rev2
> * for each change, display that change
>
> I'm not sure that we need working copies at all for this situation.
>
> The query for the delta between rev1 and rev2 already occurs in a more
> complex form for "svn update". We just dumb it down, add a new RA entry
> point, and away we go.
>
> We probably want to display a diff according to user prefs, which means that
> we need both fulltexts on the client. Given that a WC might not even exist
> (e.g. why should "svn diff -r 1 -r 2 http://svn.collab.net/repos/trunk"
> require a WC?),
Agreed.
> then we need to fetch a complete file for rev1 and then an
> svndiff for rev1->rev2, build a fulltext of rev2, then feed that to the
> user's diff.
We can't sensibly fetch the complete rev1 of a given file until we
know that the file occurs in the rev1-to-rev2 diff. So perhaps we
could request the rev1-to-rev2 diff, parse it to drive the editor, and
then as files appear in the diff request the complete rev1 for the
affected components.
Is it possible to run a second repository request and editor while in
the middle of parsing a first request? Is there any chance of one
request blocking the other leading to deadlock?
>
> Note that a lot of this fetching behavior is also required by the merge
> functionality. We should have a lot of the functionality now or RSN.
Given that I copied most of the diff code from update, copying from
the merge code is definitely the way to go!
--
Philip
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: `svn diff' progress
Posted by Greg Stein <gs...@lyra.org>.
On Tue, Dec 18, 2001 at 12:35:05AM +0000, Philip Martin wrote:
> Karl Fogel <kf...@newton.ch.collab.net> writes:
>...
> > Philip?) Same strategy, I guess: just download both files and diff
> > them client side, the downloads can be diffs against the working copy
> > revision, and/or one of the downloads can be a diff against the other
> > download, whatever works best...
>
> I have been thinking about this, but it doesn't follow on quite so
> simply from the current code. The crawler used by diff is the same as
>...
> As you say there are two (at least) ways to approach this:
>...
How about a third:
* ask the server for differences between rev1 and rev2
* for each change, display that change
I'm not sure that we need working copies at all for this situation.
The query for the delta between rev1 and rev2 already occurs in a more
complex form for "svn update". We just dumb it down, add a new RA entry
point, and away we go.
We probably want to display a diff according to user prefs, which means that
we need both fulltexts on the client. Given that a WC might not even exist
(e.g. why should "svn diff -r 1 -r 2 http://svn.collab.net/repos/trunk"
require a WC?), then we need to fetch a complete file for rev1 and then an
svndiff for rev1->rev2, build a fulltext of rev2, then feed that to the
user's diff.
Note that a lot of this fetching behavior is also required by the merge
functionality. We should have a lot of the functionality now or RSN.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: `svn diff' progress
Posted by Philip Martin <ph...@codematters.co.uk>.
Karl Fogel <kf...@newton.ch.collab.net> writes:
> Then I tried diffing two arbitrary revisions:
>
> $ svn diff -r 640:660 subversion/clients/cmdline/main.c
> svn_error: #21012 : <Trying to use an unsupported feature>
> diff only supports a single revision
> $
>
> Ah,, okay, we don't support that yet. :-) (Is that next on your list,
> Philip?) Same strategy, I guess: just download both files and diff
> them client side, the downloads can be diffs against the working copy
> revision, and/or one of the downloads can be a diff against the other
> download, whatever works best...
I have been thinking about this, but it doesn't follow on quite so
simply from the current code. The crawler used by diff is the same as
that used by update, however the diff editor doesn't build a new
working copy it just creates temporary files (and they are very
temporary, they get deleted during the crawl). This avoids the need to
create directory hierarchies, admin areas, etc.
As you say there are two (at least) ways to approach this:
Suppose we run two crawlers over the working copy, one for each
revision. Then we need some way to associate the files produced by one
editor with the corresponding files from the other, and as far as I
can see this can only be done after the crawlers have finished. So the
files need to exist after the crawl, and we need to keep track of
where in the hierarchy the files belong. I am not clear how to do
this, as the current diff editor avoids the need.
The alternative is that the first crawler runs over the working copy,
and the editor builds a temporary working copy. The second crawler
then runs over this new working copy and a second editor produces the
required diffs. Now the first crawler/editor is very like the current
update, and the second is very like the current diff, so I can see how
this would work. Lots of lovely code reuse into the bargain. There is
the overhead of constructing a complete working copy, but we need to
store the hierarchy information somewhere and a working copy is
probably the simplest way.
In fact writing this has lead me to conclude that the second approach
is the one to take, having previously been assuming that the first
would be the one!
--
Philip
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org