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

Re: Question regarding svn_ra_do_update()

From: Ph. Marek <philipp.marek_at_bmlv.gv.at>
Date: 2006-11-14 07:20:25 CET

Ben,

thank you for your answer.

On Tuesday 14 November 2006 01:08, Ben Collins-Sussman wrote:
> 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. :-)
Well, if you remember, I originally asked for some way to tell the ra layer "I
had this file at revision X, but it's changed, so please, if there's an
update, send me the fulltext":
http://thread.gmane.org/gmane.comp.version-control.subversion.devel/71057/focus=71057

To me it seems not so much a "working copy hell", more a bit of "ra layer
hell" :-)

> 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.
Well, that's how it works. So there's no way to say "Send full-text if it has
changed since rev X"?

> 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.
Thank you, I think I got that bit right.

> 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.
That's the second problem where I'd had to jump through some loops.

> > 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.
Sorry for being ignorant, but the only difference I see (against
svn_ra_do_status) are the text_deltas and ignore_ancestry arguments.

That's what I asked before - do I have to do a remote-status and then get all
needed files?

> > 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.
Well, you're right, I already feel a bit - this assumption is not only done in
the working copy layer (as I hoped), but is written over the entire ra layer
as well ...

I just assumed (yes, I know) that since subversion without text-base is work
in progress that someone had a bit of brainstorming how to implement it.

What I'd like most would be the flag "send changes to this file as full-text"
when doing an update (possibly while reporting) ...

Or possibly it would be better to get a
   svn_ra_fetch_file_parts(
     session_t session,
     char *filename,
     struct { off_t position, length; } blocks[],
     int block_count)
working - then I'd do a remote status and fetch all needed delta information
of the files.

Are there any other useful links/ideas?

Regards,

Phil

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Nov 14 07:20:26 2006

This is an archived mail posted to the Subversion Dev mailing list.