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 ?
TIA,
CU C>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Feb 19 11:36:01 2007