On 2/19/2007 5:35 AM, CodeBase wrote:
> Ulrich Eckhardt schrieb:
>> On Sunday 18 February 2007 22:59, CodeBase@web.de wrote:
>>> Assume there are 2 files in the repository which should always be committed
>>> together, such as an OpenOffice document and the PDF exported from it:
>>>
>>> /root/oo.org/mydoc.odt
>>> /root/pdf/mydoc.pdf
>> Some people consider that flawed and that only the source data should be held
>> there. YMMV.
>>
>>> Assume there are pending changes in the doc (exported to the PDF) worth
>>> committing.
>> So there are changes in both files that should be committed, right? Subversion
>> doesn't care where those changes come from.
>>
>>> C:\> svn commit --message "some reasonable message"
>>> "C:\SVNWC\oo.org\mydoc.odt" "C:\SVNWC\pdf\mydoc.pdf" --> OK
>>>
>>> Now create more changes and export them again. Repeat the step above.
>> Again, you changed both files.
>>
>>> --> Modified: ...\mydoc.pdf
>>> Error: Commit failed (details follow):
>>> Error: Your file or directory ...\mydoc.pdf' is probably out-of-date
>>> Error: The version resource does not correspond to the resource within the
>>> transaction. Either the requested version resource is out of date (needs to
>>> be updated), or the requested version resource is newer than the
>>> transaction root (restart the commit).
>> Hmmm, looks like someone else already checked in a changed version of the PDF,
>> though it's hard to tell from that message.
>>
>>> I read on the list about deleting wcprops files, but as I can't find any
>>> file of that name, the only way to get around the problem is to copy the
>>> changed file, remove the .svn folder and check it all out from scratch,
>>> then copy the changed file, again.
>> No, that shouldn't be necessary.
>>
>> Some theories:
>> 1. Something else is going on, and that is probably something you don't tell
>> us, probably something automated that modifies either your repository or
>> workingcopy.
>>
>> 2. Some tool is running amok and modifying the private metadata that belongs
>> to Subversion, e.g. some batch replace job that doesn't care about
>> write-protected files.
>>
>> In any case, it's not in what you're telling us but in what you're not telling
>> us.
>>
>> Uli
>>
>
> OK, forget about ODT and PDF, they were just meant to illustrate the
> problem.
> Assume 2 files, both are changed twice and should be checked in twice.
> The first time the check in works, the second time it fails.
>
> Noone besides me works on these files. Noone has checked in anything.
> Whenever I run into the issue, I try to update them without change.
> There are no automated tools running that modify anything.
>
> I can reproduce this problem in less than a minute.
>
> The only thing I've simplified for the sake of... well, simplicity is
> that the the file paths are longer and the files themselves are not
> actually called mydoc.odt or mydoc.pdf and my working copy does not
> reside in C:\SVNWC, but I think you guessed that anyway.
>
> Is there any debug level I can crank up ? Is there any other information
> I can provide that might help solving this ?
It would be helpful if you posted a script to reproduce the problem, so
others can see it too. Start with "svnadmin create testrepos", use
"echo mod1 >file1" kinds of instructions to create the files, etc.
Duncan Murdoch
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Feb 19 12:39:21 2007