Ticket #120 (closed defect: fixed)
Switch to "mtn automate"
| Reported by: | dhbaird | Owned by: | lele |
|---|---|---|---|
| Priority: | major | Milestone: | VersionOne |
| Component: | mtn | Version: | 0.9 |
| Keywords: | Cc: |
Description
As mentoined in by ciphergoth in Ticket #116, "mtn automate" might be a better way to interface with Monotone than the screen-scraping technique currently being used.
I suspect this will require a substantial rewrite of some code. For that reason, a good way to approach this might be to make a copy of "monotone.py" to e.g. "monotoneautomate.py" and work on that branch until the work is finished. Any suggestions?
Change History
comment:2 Changed 6 years ago by lele
Uhm, I don't see a good motivation for duplicating the unit... do you? As said, I'm going to cut a new release of Tailor (0.9.28) once we are reasonably sure #116 is fixed. With darcs its pretty easy to keep a work-in-progress branch dedicated to this ticket... I can pull from there, and not push around the patches until we are satisfied.
comment:3 Changed 6 years ago by dhbaird
If you think that is a good way to work on this, then it sounds good to me :-) I am just learning Darcs (and it is pretty fun so far) so I don't know exactly how to work with branches yet.
comment:4 Changed 6 years ago by dhbaird
Well, on second thought, I can think of a good reason for having two versions of monotone simultaneously: It means that I can install Tailor once on my system and simultaneously work on both modules: bug fixes to monotone.py while also bringing monotoneautomate.py up-to-par with monotone.py. Then, as soon as "mtn automate" is finished, we can replace monotone.py with monotoneautomate.py. OTOH, if we just have an entirely new branch altogether, then the old screen-scraping monotone.py might be neglected while we focus on the new "mtn automate" branch of monotone.py.
comment:5 Changed 6 years ago by lele
Ok then, we can arrange to use the prefix "mnt:" for the new backend... But let's first cut a new version of tailor! :)
comment:6 follow-up: ↓ 7 Changed 6 years ago by rghetta
Sure using automate will make a more stable interface with monotone.
There is already a python interface to automate, used by the "dumb" monotone server. See monotone.py in branch net.venge.monotone.dumb
Perhaps the most difficult part is replicating the history linearization trickery used by current backend. It relies heavily on having monotone computing a reasonable changeset between two arbitrary revisions. AFAIK, there is no automate command which replicates the standard "mtn diff", giving out not only the differences between files, but also the metadata (automate content_diff doesn't output metadata).
comment:7 in reply to: ↑ 6 Changed 6 years ago by ciphergoth
Replying to rghetta:
Perhaps the most difficult part is replicating the history linearization trickery used by current backend. It relies heavily on having monotone computing a reasonable changeset between two arbitrary revisions. AFAIK, there is no automate command which replicates the standard "mtn diff", giving out not only the differences between files, but also the metadata (automate content_diff doesn't output metadata).
If a feature you need is missing from automate, ask the Monotone developers to include it. Anywhere you need to use the non-automate interface to get information out of Monotone is effectively a bug.
comment:8 Changed 6 years ago by HenryN
Have rewritten all, unless the "mtn diff", the complete tailor source tailor-20070615.tar.gz or tailor-20070615.patch can have here: http://www.henrynestler.com/tailor/
"mtn log" have complete replaced with an "mtn automate certs" there.
