On 11/10/06, Ph. Marek <philipp.marek@bmlv.gv.at> wrote:
> So I do
> svn_ra_do_update(session, &reporter, &baton, Y, "", TRUE,
> &my_editor, my_baton, pool);
> reporter->set_path(baton, "", X, FALSE, NULL, pool);
> reporter->delete_path(baton, "deleted-file", pool);
> reporter->finish_report(baton, pool);
> Now my editor is driven, and I get the expected modifications from X to Y.
>
> My problem is that I *also* get the deleted file back - although it didn't
> change between X an Y!
Welcome to working copy hell. Things are much, much more complex than
you think. :-)
First, you're mixing up two concepts: delete_path() doesn't mean "the
user has run 'svn rm' on this path." If you make that reporter call,
it means, "help, I know I should have this file (or directory), but
it's missing!" The server then responds by sending the missing file
or dir.
If a file is simply *scheduled* for deletion, then there's nothing
interesting to report to the server. You still have rX of the file,
it just happens to have a local modication attached ("delete this from
the repository when you next commit"). In other words, that
schedule-delete file may very well have changed between revisions X
and Y, and the update process will still merge those changes into the
text-base as usual. The fact that the file is scheduled for deletion
is just a bit of extra metadata in the working copy, and the server
doesn't need to know about it.
If the user has actually *committed* the file deletion, and then runs
'svn up', that's a whole different story. The working copy still has
a marker in the entries file saying "this file was deleted in revision
Q", and the reporter describes the file as 'being at revision Q'
(that is, "it's from the revision where the file no longer exists").
The server then responds in one of two ways: either it says nothing
at all about that file (translation: "yep, that file is gone in the
revision you're updating to"), or it resends the file (translation:
"somebody readded that file in the meantime"). In the former case, if
libsvn_wc sees no mention of the deleted file, then it actually
removes the entry from the entries file forever.
> If I don't report it with delete_path(), it isn't sent.
> Is there some other way to define this path as "send me the fulltext, *if it
> has changed*?"
If you tell the server you have revision X, and a bunch of files
changed in revision Y, it's going to send you compressed deltas to
apply to your rX files. That's inherent in ra_do_update(), you can't
get around that.
If you use do_diff2(), you may get what you want. It's extremely
similar to do_update(), but has a text_deltas argument. If the
argument is false, then you only get a 'skeletal' report back,
indicating which files need to be updated. It's up to you to then
call ra_get_file() on each one.
> Since I received no ideas so far - how should subversion without text-base
> work?
Um, subversion without text-deltas is a tremendous, monumental change.
The idea of textdeltas is a 'built in' assumption in many, many
places. I'm not sure what you're trying to do, but get ready for
some serious pain.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Nov 14 01:09:02 2006