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
>
>
>
>
Ok, I believe I understand the problem: Without a wc there is no way for
whatever sort of client to know which revision the local copy
represents. I'll keep that in my mind.
Thanks a lot for pointing that out.
In my use case it's probably not going to be a problem, since users only
checkin files. The software-system I'm developing is the only part
performing checkouts and those are not returned to the users.
Best Regards,
Dirk
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Sep 1 18:22:38 2004