Hi Ben,
I'm extending the libsvn_client API by a svn_client_put()-function and
find it quite difficult to deal with all those batons, pools etc.. I
wrote 50 lines of code before coming to `editor->open_root(...)', just
by copying&pasting from already existing code without fully
understanding what I'm really coding.
Would you please send me the sources of your `svnput'-tool just as an
example. That would make my efforts a lot easier than they are at the
moment.
When I'm finished writing and testing my code maybe someone would like
to review it. You probably won't like to see it in subversion but it may
be provided as a patch or extra lib for those who need this special
functionallity and know what they're doing.
Best regards,
Dirk
Ben Collins-Sussman wrote:
>On Wed, 2004-09-01 at 01:47, Dirk Hoffmann wrote:
>
>
>
>>So I will definitely extend the javahl API to allow committing files
>>without needing a wc.
>>
>>
>
>Here's a little story.
>
>Over the weekend, as a fun project, I started writing a C program called
>'svnput'. It was a tiny program, designed to be run as 'svnput foo.c
>URL'. Under the hood, it would run:
>
> RA->get_latest_revnum()
> RA->open(parentURL)
> RA->get_commit_editor()
> editor->open_root(latest_revnum)
> editor->open_file(latest_revnum)
> send a txdelta against the empty stream
> editor->close_file()
> editor->close_edit()
>
>My thought is that this would address all the complaints out there about
>not being able to "upload" a single file without checking out an entire
>directory. We certainly have the API to accomplish this, after all.
>
>But in IRC, Erik Huelsmann and Greg Hudson convinced me that this was
>probably not a safe utility. While the semantics of subversion commits
>would prevent the user from overwriting the HEAD version of the file,
>there's still no guarantee that the user isn't blowing away somebody
>else's changes. For example,
>
> 1. svn cat -rHEAD URL > foo.c # fetches r12 of foo.c
> 2. edit foo.c
> 3. svnput foo.c URL # overwrites HEAD version of foo.c
>
>So what happens if somebody commits a new version (r13) of foo.c while
>the user is editing their local copy of r12? When they run 'svnput',
>they'll be unknowingly overwriting r13 with an edited copy of r12,
>effectively blowing away the r13 changes. (Sure, the r13 changes are
>still in the repository's history, but it may take a long while to
>discover that this mistake ever happened, and it's an annoying mess to
>fix.)
>
>This is why it's *so* much nicer to have a working copy. It prevents
>this sort of situation. When you commit from a working copy, the
>clients says "I'm uploading a new version of r12", and gets bounced out
>right away, rather than just overwriting whatever happens to be the
>latest version of the file. There's no way 'svnput' can know exactly
>what's being uploaded.
>
>So I think the better solution, in the long run, is to make libsvn_wc
>smarter, and come up with a way to have an .svn/entries file that only
>contains a single file, with all other siblings marked "unwanted", or
>somesuch.
>
>Anyway, I thought I'd communicate this wisdom to you, Dirk, before you
>write a java tool that does the same thing. Be wary.
>
>
>
>>Unforunately I haven't found much about how to utilize a commit editor.
>>Could you give me some pointers on this please.
>>
>>
>
>svn_delta.h. Go crazy. The comments in there are practically
>book-like, start around the comment, "Traversing Tree Deltas."
>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
>For additional commands, e-mail: users-help@subversion.tigris.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Sep 27 14:46:26 2004