First of all, the svn client library gives you a bunch of 'high level'
APIs that do the things a typical svn client wants to do... and all of
the commands assume you have a working copy and a network available.
In other words, libsvn_client APIs are built on top of libsvn_wc and
libsvn_ra, and makes much use of both of those libraries.
If you want to get and put information to a repository *without* a
working copy, then you must use libsvn_ra only. That's what the
'svnput' email was demonstrating.
Yes, you could use the RA library to lock a file, then fetch it, then
put a new version into the repository, then unlock the file. All of
the APIs in libsvn_ra are available to do that. And it would also
guarantee that you're not overwriting someone else's commit (since
you've locked the file.)
> I understand that using working copy svn is automatically merging my
> modifications (is this correct?)
Um, sure, if you have a working copy, and run 'svn update', then
repository changes are merged into your working copy. This is how
both CVS and Subversion work. This is nothing new.
>
> But an automatic merging can be VERY dangerous.
Huh? If there are conflicts, then conflict markers are inserted and a
human has to resolve them. This is how CVS and Subversion have always
worked. There's nothing dangerous going on.
>
> Isn't the client API cretaing a lock on the database when I use the checkout
> client API to avoid this situation?
There's no such thing as a 'read' lock. When you run 'svn checkout',
you get an immutable tree. If people are committing changes during
your checkout, they have no affect on you.
>
> If so, the only condition is to be sure to lock the repository when I get my
> copy....
In your standalone C program, you only need to lock the *one* file
when you fetch it, so that you can be sure nobody has committed a
newer version before you upload your own new version.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jan 26 08:16:59 2007