Environment: Windows XP (2002 sp2), cygwin (bash version
3.2.25(17)-release (i686-pc-cygwin)), Symantec AntiVirus, svn client
1.4.5 (r25188), svn server 1.4.2 (r22196)
I did something like:
$ svn mkdir ~/project/branches/newbranch
$ svn copy ~/project/trunk/directory ~/project/branches/newbranch
svn: Can't move '~/project/.svn/tmp/entries' to
'~/project/.svn/entries': Permission denied
$ ls ~/project/branches/newbranch
<snip> Long list of everything that is supposed to be there </snip>
$ svn commit ~/project/branches/newbranch
<snip> everything commits ok </snip>
$ vi ~/project/branches/newbranch/directory/somefile
$ svn commit -m "Changed!" ~/project/branches/newbranch/somefile
<snip> commit ok </snip>
$ svn log ~/project/trunk/directory/somefile
---------------------------------------------------------------------
r2880 | wfinn | 2008-01-25 12:30:00 -0800 (Fri, 25 Jan 2008) | 1 line
Changed!
---------------------------------------------------------------------
Searches online led me to believe it was the AntiVirus software not
releasing a lock. I disabled the AntiVirus, did everything again, no
errors. I get a similar error nearly every time I perform actions that
affect a large number of files at once (when the AntiVirus is running)
but never get the error when the AntiVirus is not running.
-----Original Message-----
From: Ryan Schmidt [mailto:subversion-2007b_at_ryandesign.com]
Sent: Thursday, January 17, 2008 1:08 PM
To: William Finn
Cc: Talden; users_at_subversion.tigris.org
Subject: Re: svn copy failed, commits go to trunk?
On Jan 17, 2008, at 14:23, William Finn wrote:
> Talden wrote:
>
>> On Jan 18, 2008 7:40 AM, William Finn wrote:
>>
>>> I'm fairly new to svn, so maybe I'm doing something stupid, but it
>>> seems to
>>> me right now that svn has the problem. I did something similar to
>>> this:
>>
>>
>> You're missing a whole lot of important information needed to give
>> assistance.
>>
>> When you 'checkout' you specify which part of the repository you're
>> checking out. in your case it's unclear and so the best
>> assumption we
>> can make is that you've checked out the entire repo.
>>
>> EG if your repo structure is
>>
>> projectX/
>> branches/
>> tags/
>> trunk/...
>>
>> It would be usual to check out "projectX/trunk" or one of the
>> branches
>> or one of the tags.
>>
>>> svn copy trunk branch
>>
>> Usually you'd create a branch with URL to URL copies ensuring that
>> the
>> branching operation is atomic. In addition you can't normally do it
>> locally because you would normally have the parent of the branches
>> and
>> trunk folder checked out (though if you're creating a mixed revision
>> tag or branch then you might).
>>
>>> svn commit -m"Yay branching!" branch
>>
>> You probably should revisit the Subversion book for a guide on
>> typical
>> layouts and typical branching practices.
>
> I was trying to keep my example independent of my personal setup by
> using generic names. Sorry I didn't make that clear.
>
> I checked out a specific project: trunk, branches, & tags and am
> familiar with the common practices of branching and tagging, but
> that is
> really irrelevant to the issue at hand.
>
> From what I understand, please correct me if I'm wrong here, I _can_
> create copies using 'svn copy localfile1 localfile2' then commit said
> copy. This will have the same net effect as 'svn copy url1 url2'
> assuming nothing changed in the repository since my last update (or
> maybe it creates a new file instead of a delta, doesn't matter for
> this)
>
> And so I did create the copy based on my local version.
>
> My problem is this:
> 1) I executed svn copy (all local) to create a branch
> 2) Copy created, with an error about a log file that seemed irrelevant
> 3) The copy committed just fine (no errors or warnings)
> 3) All work on the copy was applied to the original
>
> Imo, what should have happened if the copy of the .svn directories
> failed in some way is it should have failed completely, not half way.
> It effectively created a symlink by copying the files and having
> both of
> my local copies pointing to the original.
>
> This isn't about best practices or my specific install, this is about
> how an application behaves when something fails.
I don't think I've heard of Subversion failing in this way before.
And we're still missing enough information to try to answer this
question. What version of Subversion do you have on the client and
server? What OS is on the client and server? What is the exact error
message you encountered with the copy command? Can you give me a
reproduction recipe that will recreate the problem (from scratch) on
my machine?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-01-25 21:43:32 CET