On 3/12/2006 5:22 PM, Craig Lawson wrote:
> Thank you for your replies.
>
> I tried specifying the current directory with ".", but received the same
> result. Also, my reading of the subversion manual is that the current
> directory is the default.
Yes, the . is optional in most commands.
> The FSFS bug link seems a lot like mine, except I don't have any
> branches. I used only svn move, add, and remove of files and
> directories, modified some files, and updated before commit. I am using
> FSFS only.
>
> But I still can't commit. How do I get out of this jam?
I'd do the following:
Back up the bad copy somewhere, so that if you make a mistake and change
it while doing the repairs you can start again. Then check out a new
working copy. Try to do all the moves and removes on the new copy and
commit just those changes. Then copy everything except the .svn
directories from the bad working copy over, add the new files, and do
another commit. Finally, throw away the bad working copy (but keep the
backup); it'll likely be a pain to update it, because of all the file
renames. (Subversion won't check out a new file on top of one with the
same name.)
I think the first commit (the one with the moves and removes) is likely
the one that will be troublesome; if you succeed with it the rest should
go smoothly.
If you have trouble with the moves and removes, you could try doing all
the moves and removes in the repository, and check out a working copy
after those.
By the way, you said you were new at Subversion, so I want to point out
that this sort of problem isn't common. I've occasionally run into
trouble when doing branching and merging, but never doing the sorts of
things you were doing -- and I'm pretty sure all the problems I saw were
my own fault.
Duncan Murdoch
>
> Thanks,
> Craig.
>
>
>
> Res Pons wrote:
>> Your file name argument is missing. Either specify a filename or a dot
>> '.' for the entire directory
>
>
> Duncan Murdoch wrote:
>> On 3/12/2006 3:47 AM, Craig Lawson wrote:
>>> Hi subversion users,
>>> I'm new to the group and to svn. I'm using 1.2.3-r2 on gentoo to
>>> manage a web project, and just recently moved a bunch of files and
>>> directories around. When I commit, I get:
>>>
>>> $ svn commit -m "big change"
>>> (Adding, Deleting, Sending, etc.)
>>> Transmitting file data ............................svn: Commit failed
>>> (details follow):
>>> svn: Invalid change ordering: new node revision ID without delete
>>>
>>>
>>> Just to be sure I hadn't messed things up with too much fiddling, I
>>> started from a fresh copy and repeated my svn commands, synchronizing
>>> file and directory contents with the failed working copy but keeping the
>>> .svn content independent. Same result.
>>>
>>> Is this an svn bug? Sure looks like a bug. svn appears to be telling me
>>> that it cannot construct a valid transaction even though I used valid
>>> svn commands. What to do next?
>> I think it looks like the bug discussed here:
>>
>> http://www.nabble.com/FSFS-bug-with-mixed-revision-commit-t15867.html
>>
>> In that thread it was triggered by doing a copy from the working copy
>> to a new branch, and the workaround was to do the copy in the
>> repository, and then switch the working copy. I.e. instead of
>>
>> svn cp . URL:newbranch
>>
>> do
>>
>> svn cp URL:trunk URL:newbranch -m"create branch"
>> svn switch URL:newbranch
>> svn commit -m"big changes to new branch"
>>
>> (where URL:trunk and URL:newbranch aren't to be taken literally, of
>> course: put in the actual URL of your original copy).
>>
>> At least I think that's a correct summary....
>>
>> Duncan Murdoch
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
>> For additional commands, e-mail: users-help@subversion.tigris.org
>>
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sun Mar 12 23:43:06 2006