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

Re: Flailing

From: Madan U Sreenivasan <madan_at_collab.net>
Date: 2005-09-06 08:28:06 CEST

On Mon, 2005-09-05 at 17:17, Harold Naparst wrote:
> I am trying to commit my changes to subversion, and everything I do
> produces an error.
Well, most of the commands require a context. Some run on the wc and
some run on the repository

Points to remember.
- A URL always points to a repository
- A relative or absolute path always points to a wc
(or thats how svn sees it)
Pl. find other comments embedded.

> What am I doing wrong. The checkout command, which executed
> successfully was:
>
> svn checkout file:///usr/local/svn/trunk client
checkout works on a repository(the file:// url here) and results in a
local dir(client here) which is the working copy.
The usage of this command is correct.
>
> Here's what's happening now:
>
> boinc@happiness:~/seti_boinc> svn commit
> svn: '/home/boinc/seti_boinc' is not a working copy
You are outside the working copy. 'svn commit' without any parameters
should be executed from within a working copy. Your seti_boinc is not a
working copy. Thats why this didnt work.
> boinc@happiness:~/seti_boinc> cd client
> boinc@happiness:~/seti_boinc/client> svn commit
Correct Usage.
> svn: Working copy '/home/boinc/seti_boinc/client' locked
> svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for
> details)
Didnt work as a previous update/commit has prolly been abondoned and a
lock has not been removed.
> boinc@happiness:~/seti_boinc/client> cd ..
> boinc_at_happiness:~/seti_boinc> svn cleanup file:///usr/local/svn
Cleanup works on a working copy and not a repos(URL). So this usage is
wrong.
> svn: Cannot cleanup 'file:///usr/local/svn': not a directory
> boinc_at_happiness:~/seti_boinc> svn cleanup file:///usr/local/svn/trunk
> svn: Cannot cleanup 'file:///usr/local/svn/trunk': not a directory
> boinc_at_happiness:~/seti_boinc> svn update file:///usr/local/svn/trunk
> svn: 'file:///usr/local/svn' is not a working copy
an update can only be run on a working copy and not on a URL(repos)
> boinc_at_happiness:~/seti_boinc> svn checkout file:///usr/local/svn/trunk
> client
> svn: Working copy 'client' locked
> svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for
> details)
the client dir already exists and hence this cant be done ( more
specifically the client dir (the wc) is locked and hence the message.
> boinc_at_happiness:~/seti_boinc> svn cleanup file:///usr/local/svn/trunk
> client
> svn: Cannot cleanup 'file:///usr/local/svn/trunk': not a directory
no cleanup on a URL(repos) again...
> boinc@happiness:~/seti_boinc> svn cleanup client
> svn: 'client/.libs' is not a working copy directory
your client dir prolly has a subdir called .libs which is not a wc
directory.... but I cant make out why the cleanup hasnt happened(as
shown by your subsequent steps) for the other dirs in client ?!
> boinc_at_happiness:~/seti_boinc> svn checkout file:///usr/local/svn/trunk
> client
> svn: Working copy 'client' locked
> svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for
> details)
> boinc@happiness:~/seti_boinc> svn commit client
client is still locked. Not cleanedup yet.
> svn: Working copy '/home/boinc/seti_boinc/client' locked
> svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for
> details)
> boinc@happiness:~/seti_boinc>

the cleanest way to do a cleanup is to cd into the working copy(
~/seti_boinc/client in your case) and execute
svn cleanup

which is what Gary Thomas has suggested.

All of these have been covered by the book. Pl. read the book at
http://svnbook.red-bean.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Sep 6 08:21:17 2005

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

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