Ben Collins-Sussman wrote:
> 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
Does svn cat show what revision you received?
If so, and if your little utility could also display the new revision
you created, then the user could see right there that oops, I smashed
someone's changes because it skipped a rev number.
Taking that a step further, your utility could accept a rev number on
the command line and check to make sure that it was creating the
successive rev number to the one given, (if the API supported that).
Otherwise, it would abort and show a warning to the user that he's out
of date.
-joel shellman
---------------------------------------------------------------------
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:37:22 2004