13:56 < robtaylor> lelit: well, for example, when syncing svn to darcs, the svn
                   commit numbers and ocmmiters get placed in the darcs patch
                   mesage.. i want to store the darcs patch -> svn commit
                   number equivalence in a file, rather than expose them in the
                   message
13:56 < robtaylor> lelit: ah, sounds cool
13:56 < lelit> yes, then: in the post commit you can do that
13:57 < robtaylor> lelit: how would that work for resyncing later
13:57 < robtaylor> ?
13:57 < lelit> tailor doesn't use *that* info (i mean, not from the commit
               mesgs)
13:57 < robtaylor> ahhh
13:57 < lelit> so I don't foresee the problem...
13:57 < robtaylor> how does it tell?
13:58 < lelit> from the state file
13:58 < robtaylor> interestingly when i did a 2 way sync svn->darcs the add
                   patch to darcs, darcs-> svn, i ended up with all my commits
                   duplicated in teh svn
13:58 < lelit> that file contains the last applied patch
13:58 < robtaylor> 1st lor the originals, then 2nd lot done by tailor
13:57 < lelit> tailor doesn't use *that* info (i mean, not from the commit
               mesgs)
13:57 < robtaylor> ahhh
13:57 < lelit> so I don't foresee the problem...
13:57 < robtaylor> how does it tell?
13:58 < lelit> from the state file
13:58 < robtaylor> interestingly when i did a 2 way sync svn->darcs the add
                   patch to darcs, darcs-> svn, i ended up with all my commits
                   duplicated in teh svn
13:58 < lelit> that file contains the last applied patch
13:58 < robtaylor> 1st lor the originals, then 2nd lot done by tailor
13:58 < robtaylor> ahh
13:59 < robtaylor> hmm, guess i should keep seperate state files for forwards
                   and backwards
14:00 < lelit> yes, that would help :)
14:02 < robtaylor> for darcs, how does it tell that an older patch hasn't been
                   pushed to the tree?
14:03 < lelit> oh, darcs is special, as always :) tailor just "darcs pull
               --dry-run" and parse the output, the grabs a patch at a time
14:05 < robtaylor> so then what's stored in the state file? a list of already
                   synced patch names?
14:05 < robtaylor> oh,i see
14:05 < robtaylor> =)
14:05 < lelit> no, the last one applied plus the pending (aka, not already
               applied) ones
14:05 < robtaylor> argh
14:05 < robtaylor> i see my issue
14:05 < lelit> have you read zooko's papers on the wiki?
14:06 < robtaylor> for 2 way sync, you *need* to share a state file
14:07 < robtaylor> as when youve gone A->B, when you next go B->A it needs to
                   skip the patches that went A->B in teh 1st place
14:07 < lelit> uhm, why? Oh, well, that could be a job for a pre-commit hook:
               with them, you can arbitrarily skip patches...
14:09 < robtaylor> hmm, can i access the state file from the precommit hook?
14:10 < robtaylor> basically when you go B->A after A->B, you need only start
                   at the last patch you pulled from A->B
14:10 < robtaylor> hmm
14:11 < robtaylor> but that would probbaly break if B is darcs
14:11 < lelit> you were talking about keeping trace of applied patches in an
               external file... that's the way to go, since the state file
               forget patches as they get applied!
14:12 < robtaylor> yep, i think you're right
14:12 < robtaylor> i need a precommit hook that store each patch equivalence in
                   an external file
14:12 < lelit> you must keep the "source" information, that is, if patch P is
               coming from svn, then there's no reason to push it again going
               darcs->svn
14:12 < robtaylor> or if the patch already exists there, it skips it
14:12 < robtaylor> yep
14:13 < robtaylor> hmm, i thinki can do that
14:13 < robtaylor> lelit: is there docuemntation for what info i have access to
                   in a precommit hook
14:13 < lelit> basically the "context" and the patch in question. There should
               be an example in the README
14:14 < lelit> there's one that "fix" the author of the patch: that hook
               returns the "new" patch, or None to mean "skip this"
14:15 < robtaylor> cool
14:16 < robtaylor> lelit: do i get both sets of patch info
14:16 < robtaylor> meh ignore that =)
14:16 < lelit> "both sets" ?
14:16 < lelit> no, it gets called once per patch
14:16 < robtaylor> i didn't mean to say that =)
14:16 < robtaylor> (stray enter press ;))
14:17 < robtaylor> so, say i'm going darcs -> svn, do i have access to the
                   patch's id (the md5summed bit?)
14:17 < lelit> yes
14:18 < lelit> as "patch.hash"
14:18 < robtaylor> rock, and svn, the changeset id?
14:18 < robtaylor> hmm, is this going tohave to be special-cased for each repo
                   type?
14:18 < lelit> yes, as patch.revision"
14:20 < robtaylor> or maybe i can patch tailor to have a patch.unique_id thats
                   the appropriate thing depending on the source type
14:21 < lelit> yes, that may be an option: it would be a matter of promoting
               "hash" to the abstract class
14:29 < robtaylor> lelit: interesting case..
14:30 < robtaylor> svn bracnhes..
14:30 < robtaylor> argh
14:32 < lelit> branches are completely different beasts
14:34 -!- ScribusT [n=ScribusT@adsl148-40.aknet.it] has joined #tailor
14:35 < robtaylor> lelit: yes indeed. i think theonly answer maybe 'don't do
                   that'
14:35 < robtaylor> but maybe usinganything otherthan darcs would be ok ;)