tailor fails to replay one change set during librtorrent svn->monotone mirroring

[wilx]

Tailor failed to reply one change set during mirroring of librtorrent. Log and config files will be attached.

[wilx]

log

[wilx]

config file

[rghetta]

apparently svn doesn't record the deletion of some files, so mtn doesn't drop them and complaints at commit time.

[lele]

Uhm, I tried to replicate the case, but

1. the rtorrent itself completed without errors
2. the libtorrent failed at revision 219, with the following error:

   18:39:49 [I] Changeset "219"
   18:39:49 [I] /tmp/75/mtn-rtorrent/libtorrent $ svn update --ignore-externals --revision 219 .
   18:39:57 [I] [Ok]
   18:39:57 [I] /tmp/75/mtn-rtorrent/libtorrent $ mtn drop --recursive src/content/priority.h
   18:39:57 [I] [Ok]
   18:39:57 [I] /tmp/75/mtn-rtorrent/libtorrent $ mtn commit --author rakshasa --date 2005-01-16T21:21:32.756410 --message-file /tmp/tailorUXJONsmtn .
   18:39:57 [W] [Status 1]
   18:39:57 [E] Monotone commit said: mtn: abuso: nessuna modifica da salvare
   
   18:39:57 [C] Couldn't replay changeset
   18:39:59 [I] 371 pending changesets in state file
   18:39:59 [C] Upstream change application failed
   Failure applying upstream changes: /tmp/75/mtn-rtorrent/libtorrent $ mtn commit --author rakshasa --date 2005-01-16T21:21:32.756410 --message-file /tmp/tailorUXJONsmtn . returned status 1
   

Effectively, at release 219 subversion deletes a single file:

$ svn log -v -r 219
------------------------------------------------------------------------
r219 | rakshasa | 2005-01-16 22:21:32 +0100 (dom, 16 gen 2005) | 1 line
Percorsi cambiati:
   D /trunk/libtorrent/src/content/priority.h

and tailor migrated this into a mtn drop, but still monotone did not find anything interesting to do:

[19:06:36] lele@paci:libtorrent $ mtn status
nessun cambiamento

rgh, any idea on what's going on here?

[lele]

The problem is simple: you cannot do "mv a b; svn move a b", because svn wants to do that itself. BTW, any brave svn 1.4 early user to confirm that (cannot) happens under the just released new version?

So, tailor tries to restore the old name just before spawning svn mv. This fails when upstream "reorganize" their sources, for example doing

$ darcs mv tests/README ./README.tests
$ darcs mv tests src/tests

Tailor clearly should restore the dirname first, and these may be tricky... but maybe under DisjunctWorkingDirectories it may be easy: In that modality, tailor does a rsync between the two directories: why not perform a double pass: replay the changeset twice, one before, and one after the rsync?

Exposing the idea on IRC, _keturns sparkled an better idea: in the scenario, a second pass isn't effectively needed: the README could be actually tweaked a little, to adjust its text with the new location of the tests, ok, and the rsync will take care of that, updating the moved copy... so the final "svn commit" should recognize that automatically...

This is so simple I simply cannot resist :)

Do you see any case for a second pass, or any other glitch in the idea?

[lele]

This should be fixed by [1281].

[lele]

Ouch, I was working on a different ticket, #65, but got distracted... Scratch the comment above, sorry.

[rghetta]

Hrm, monotone complaints if it finds nothing to do. Tailor has a specific test for this event, but is linked to the english message "misuse: nothing to do". You're using the italian translation, so the string doesn't match and tailor aborts :-(

Why monotone doesn't find anything to do even after a drop is something worth a look, though.