Using the svn_client API would be much easier.
Any plan in considering the working copy on a single file
instead of the entire directory: in my project repository and
local copy have different structures.
In regard to the lock, I was not talking about a "read lock" but I was
considering a different scenario.
What is happening if both the working copy AND the repository
have been changed when I do a "svn update"?
Isn't it a good practice to "lock" the repository when I start doing
a modification in my local copy?
Stefano
-----Original Message-----
From: sussman@gmail.com on behalf of Ben Collins-Sussman
Sent: Fri 1/26/2007 2:16 AM
To: Stefano Righi
Cc: dev@subversion.tigris.org
Subject: Re: Checkin without working copy
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.
Received on Fri Jan 26 17:21:51 2007