[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Checkin without working copy

From: Ben Collins-Sussman <sussman_at_red-bean.com>
Date: 2007-01-26 08:16:43 CET

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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.