I found this posting into the mailing list repository and I have a comment:
Is it possible to lock the repository in reference to a file, using a lock API?
In this case it would be possible to have a similar svngetwithlock to lock the repository
while I am working on my local file.
I understand that using working copy svn is automatically merging my modifications (is this correct?)
But an automatic merging can be VERY dangerous.
Isn't the client API cretaing a lock on the database when I use the checkout client API to avoid this situation?
If so, the only condition is to be sure to lock the repository when I get my copy....
Am I missing something?
Stefano
Date: Wed, 01 Sep 2004 10:39:06 -0400
From: Joel Shellman <joel@ikestrel.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Subject: Checkin without working copy
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
Received on Thu Jan 25 23:28:58 2007