[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: Peter Lundblad <plundblad_at_google.com>
Date: 2007-01-26 17:36:50 CET

Stefano Righi writes:
>
> Using the svn_client API would be much easier.

I'd say that using the RA library isn't that hard either. Did you have
a look at the API?

> 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.
>
I don't know of any plans to implement this (there's the sparse checkouts
branch, but I don't know if that could do what you want).
A problem with single file working copies is that you need to store the
metadata somewhere, so you need the context of a directory (or a central
database or whatever) anyway.

> 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"?

The changes are being merged together. If changes are being made
to the same regions of the files, or if the file is binary and hence
can't be merged, a conflict is signalled and the user has to resolve it
manually

> Isn't it a good practice to "lock" the repository when I start doing
> a modification in my local copy?
>

This is one way of working, but svn mainly implements the copy-modify-merge
model. To simplify working with binary files, there's the locking
feature that makes it possible to work exclusively on a file. This
is described more in the first chapter of the Subversion book at
svnbook.red-bean.com, which might be a good read.

Thanks,
//Peter

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jan 26 17:37:38 2007

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