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
Received on Wed Sep 1 16:26:15 2004