Sync algorithm for TicGit/Kipling

[Aslak Hellesøy]

I'm about to add sync capabilities to Kipling so that tickets/cards
can be synced between a git repo and an online tracker like
Lighthouse. Since Scott is also planning to implement a similar
feature for TicGit, I'd like to share some ideas here.

The thing is, I'm a little blank on this. Do you have a particular
syncing algorithm in mind? I'd like to deal with the following
situations:

1) There is a new ticket in Git => Create it in Lighthouse
2) There is a new ticket in Lighthouse => Create it in Git
3) An existing ticket that exists in both places has been updated in
Git => Update it in Lighthouse
4) An existing ticket that exists in both places has been updated in
Lighthouse => Update it in Git
6) An existing ticket that exists in both places has been updated in
Git and Lighthouse => Try to merge, bail if it can't be done without
conflict

Does this sound reasonable? Any thoughts about how to detect the
various scenarios?

Cheers,
Aslak

[Scott Chacon]

I was actually going to tackle this a bit differently, I think.  I was planning to implement lighthouse fetch and push operations, making lighthouse act like a git remote.  The fetch would translate everything in lighthouse into the TicGit file layout in a separate branch ('lighthouse/ticgit') and commit it if anything had changed since the last fetch. 

Then I can diff and inspect and merge using the same tools I use with any other remote.  Then I can push, much like i would do to a public server, which would take everything in my local ticgit branch that comes up in a diff to the lighthouse/ticgit branch and add/update/remove the lighthouse tickets.  The main advantage of this is that I can re-use all the merge/inspect logic that I will have to write for working with remotes.  Plus, then I have a local history of the lighthouse data, which may be kinda cool.

Hope that makes sense, but I'm not sure if that would work as well with your layout or not.

Scott