[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: Stefano Righi <StefanoR_at_ami.com>
Date: 2007-01-26 17:21:34 CET

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

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.