You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by "Crucius, Wesley" <WC...@sandc.com> on 2004/03/25 22:53:17 UTC

svn delete reports 'xxx.c is not under version control'

Hopefully someone has a easy suggestion for me on this one.  I've created a
VBScript (which I'll be happy to share if anyone thinks it's worthwile) that
is calling the command-line svn client to check-in and tag lots of source
history maintained in zip files.  

The script does the following:
1. snapshots the file names contained in the target WC directory
2. clears out the files in the target WC directory
3. unzips the zip file into the target WC directory
4. svn add(s) any 'new' files that the unzip operation 'created'
5. svn delete(s) any 'old' files that are were present @ step 1 and are
'gone' now
6. svn commit(s) the parent folder
7. tags the trunk.  (I know, but every zip file represents all the source of
a given release)

This is working great for the most part, but I have a minor problem that I'm
pretty sure is the result of changes in the case-ness of a file name.

At ver347a.zip the file chstates.c shows up in the project for the first
time

Unzipping:
  inflating: D:/SVNWork/PQP/8051-mv/trunk/chstates.c  

Adding:
svn add "D:\SVNWork\PQP\8051-mv\trunk\chstates.c"
A         D:\SVNWork\PQP\8051-mv\trunk\chstates.c

Committing:
svn commit "D:\SVNWork\PQP\8051-mv\trunk" -m "Initial import of ver347a"
Adding         SVNWork\PQP\8051-mv\trunk\chstates.c
Transmitting file data .......
Committed revision 853.
svn copy "svn://localhost/PQP/8051-mv/trunk/"
"svn://localhost/PQP/8051-mv/tags/ver347a" -m "Tagging the initial import of
ver347a"


Then, a little while later in the process at ver348, chstates.c no longer
exists:

Deleting:
svn delete "D:\SVNWork\PQP\8051-mv\trunk\CHSTATES.C" -m "Removal of
CHSTATES.C at ver348"
svn: Use --force to override this restriction
svn: 'D:/SVNWork/PQP/8051-mv/trunk/CHSTATES.C' is not under version control


Note that the svn delete command is specifying the deletion of 'CHSTATES.C'
now, instead of 'chstates.c'.  Somewhere in between 347a and 348 the file
'chstates.c' was renamed...  Is my only recourse to build in the logic to do
a three-step-rename when I detect a change in case-ness?  If it's not
obvious from the 'VBScript' statement, the OS is Windows, specifically 2k,
on both the client and the [svnserve]r at this time.  The server is likely
to become Apache on win2k at some point, would this help or is this a Win
client issue?

Thanks,

Wes

Re: svn delete reports 'xxx.c is not under version control'

Posted by Ben Collins-Sussman <su...@collab.net>.
Crucius, Wesley wrote:

> Note that the svn delete command is specifying the deletion of 
> 'CHSTATES.C' now, instead of 'chstates.c'.  Somewhere in between 347a 
> and 348 the file 'chstates.c' was renamed...  Is my only recourse to 
> build in the logic to do a three-step-rename when I detect a change in 
> case-ness?

I think so, yes.  It's painful.  I think you could do a server-side move 
to fix:  'svn mv URL1 URL2', since the subversion repository is both 
case-sensitive and case-preserving.  Specify your URLs carefully.



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org