restarting the darcs source backend skips failed changesets

[wfranzini]

Using the darcs source backend I've observed the following behavior:

• the target (aegis) back-end fails
• the state file seems (to me) to correctly register the last successfully applied change-set

however starting tailor again with the very same conditions skips the failed change-set, while I was expecting the same failure.

I think the darcs source back-end should obliterate a failed change-set before quitting.

[wfranzini]

project.state file

[wfranzini]

The following is the last change applied by the darcs source backend:

$ darcs changes --last=2 --reverse
Sun Jun 25 01:11:57 CEST 2006  lele@nautilus.homeip.net
  * Use a common ancestor to recognize tailor exceptions

Sun Jun 25 01:12:08 CEST 2006  lele@nautilus.homeip.net
  * Split the monolithic repository.py into smaller units
  The repository subclass of each backend is now in the same unit that
  implements its working dir, under the vcpx.repository subpackage.
  This has several advantages: the obvious of keeping related code closer
  and the ability of lazy load only the needed unit, as it was already done
  for the working dir subclasses.
$ 

while the last committed on the aegis target is:

$ ael ph -p tailormirror.0.9 | tail -2
1145    Fri May 30      1187    Use a common ancestor to recognize tailor exceptions
        13:42:55 2008
$

[lele]

Yes, that's expected!

Consider this:

>>> from vcpx.statefile import StateFile
>>> sf = StateFile('project.state', None)
>>> print sf.lastAppliedChangeset()
Revision: Use a common ancestor to recognize tailor exceptions
Date: 2006-06-24 23:11:57+00:00
Author: lele@nautilus.homeip.net
Entries: tailor(UPD), vcpx/__init__.py(UPD), vcpx/config.py(UPD), vcpx/cvsps.py(UPD), vcpx/project.py(UPD), vcpx/source.py(UPD), vcpx/tailor.py(UPD), vcpx/target.py(UPD)
Log:

The lastAppliedChangeset() is the changeset that tailor has been able to fetch and apply (from the source) and to replay and commit (on the target).

Your case shows that the source backend has been able to do it's work, ie pulling and applying the next patch, but an error occurred while replaying it on the target, and thus it's still "pending" there.

At next run, tailor will retry to commit that patch on the target, before going on.

Maybe the source backend could unpull (in darcs parlance) the applied-but-not-replayed-and-committed patch, but I do not see an obvious advantage of doing that. Do you?

[lele]

As explained, this is not a bug. Feel free to reopen it, if you have other arguments.

[wfranzini]

Bug confirmed by another user:

 http://permalink.gmane.org/gmane.comp.version-control.tailor/1085

[lele]

Rethinking the issue, it may be related to the StateFile machinery. I broke it recently and it's been so for a few weeks. Given that Miklos experienced the problem well before that, I can only assume it had some glitch even before then :)

Anyway, if that's the case, it should be fixed, now. I just pushed [1594] that should prevent it happens again.

[lele]

For the history, what I think it has happened is the following:

Prologue:

• the patch N-1 has been applied on the source
• after application, the source backend (darcs in this case) completed the ChangeSet with the actual list of entries
• the changeset got committed on the target
• the statefile was notified about that, and stored the changeset (modified, at that point) in the journal
• patch N came in: the source backend correctly applied that too and loaded the entries
• at this point, the target backend fails, the process is aborted, and the statefile is closed: the StateFileJournal at this point still contains (the modified) patch N

Epilogue:

• at next run, the StateFile is consulted to know the next pending changeset
• it notices the presence of the journal, and proceeds with the finalization
  • the last applied changeset is loaded from the journal
  • each pending changeset is compared to the last applied one, skipping them until either one changeset matches or the EOF condition is met
  • the queue is rewritten to the file
• if there are still pending changeset, Tailor proceeds processing them; otherwise it asks upstream for new changesets, and the process restarts

The bug I introduced considered also the entries of the changeset in the comparison: for this reason, the last point above always reached EOF, triggering the fetch of new changesets from upstream. Since patch N was already applied on the source, it isn't queued anymore...

I hope this put some light on the problem.