Re: [Monotone-devel] Question for Windows automate users
2009/2/22 Timothy Brownawell :
> On Sun, 2009-02-15 at 10:27 -0800, Zack Weinberg wrote:
>> What's the intended effect of the make_io_binary() call in
>> automate::exec()? It looks like we're setting stdin and stdout to
>> binary mode for any automate operation, but that doesn't seem right --
>> if you're just running one automate command inside a batch file or
>> something you'd want DOS line endings, wouldn't you?
>
> get_file / get_file_of and put_file need to be binary-safe, so they work
> with binary files. stdio needs to be binary-safe, so the byte counts
> don't get messed up.
>
> The others probably don't care, but making them not binary (1) would be
> inconsistent, and (2) would mean that they'd give slightly different
> output when run through stdio. Not sure how much these points actually
> matter, especially for the commands that generate lists (tags,
> ancestors, inventory) rather than dumping items (get_current_revision).
Agree in general. Summarizing:
1. Automate stdio must be always binary safe and consistent amongst platforms.
Imagine automate client working on windows reading from some ssh-ed
process on some unix (or vice versa). How one can know if that remote
one is unix/windows?
2. Standalone command execution:
For first-class data (revision text, cert value, file content, diff)
value it MUST be binary safe.
Invocation of:
monotone au get_revision RID | sha1sum
must print RID regardless of platform and shell (that's also problem
with sha1sum tool which must read in binary mode but we have to make
monotone work as expected in this scenario).
Synthetic, query like data it can have native line-end so it can be
successfully parsed using platform shell utils (btw are there any
_other than unix-like_ shell text tools on any platform?). I think it
covers "any revision list", tags, keys, inventory, graph, options,
attibutes (really? **).
Packet IO is already line-ending agnostic and base64 meaning doesn't
change regardless of LE sequence. Native line-ending can be used.
> Perhaps default to binary for stdio and maybe get_file(_of)/put_file (or
> maybe not, since most files will probably be text files) and text for
> the others, with a --binary={yes|no} option to override this?
Not good idea IMHO. If there should be any option here it should be
monotone-wide and be something like --line-ending={native,CR,LF, CRLF}
(or unix,windows,mac). But that's pandora box we don't want open. It
was discussed several times without any reasonable result other than
it's a minefield.
**Hmmm.
Attribute value is part of revision text and i bet it can include
newline inside. So it's value should also be LE-consistent.
Regards,
ZZ
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] log options and staying on the current branch
On Sun, Feb 22, 2009 at 9:25 PM, Richard Levitte wrote: > Personally, I'd find it irritating to have the history broken off just > because it went into another branch for a while... Maybe we should > The use case that gets me more often than not is when I'm working on a branch, and trying to see what has changed on that branch, without wandering off looking at things on some other branch that was propagated into the branch I'm working on. I've mentioned this a few times in the past, and people generally come back with the big crazy pipe contraption from my previous message, which does work but is hardly intuitive. The fact that I have a script lying around with that thing in it is a good indication that I've needed it from time to time. Aside from using the --branch option, would you find the other options (--date, --author, --message) useful? I've found myself wanting to be able to log changes by a specific author a few times with subversion which doesn't do this either. I notice that git does allow log by --author and it is something that I would have used on occasion had it been available. > think about having a ~/.monotone/opts file to give the users a > possibility to have their own default option values or somesuch... There is the new get_default_command_options hook coming in 0.43 that essentially does this. One thing I was trying to avoid was having to come up with a bunch more crazy option names (log --please-stay-on-this-branch) when the existing ones fit the purpose reasonably well. Either way, I'm actually writing to remind you to add something in > NEWS, even though you're working in your own branch. Just to make > sure it's not forgotten when the time comes to propagate this back > into the main branch :-). Could you please? > When working on experimental branches I generally avoid doing things like this until I get some encouraging feedback that indicate the branch has a chance of being worthy of merging to mainline. This branch (like many others) needs not only a NEWS entry, but a few feature specific tests and documentation updates before it's ready for merging. I'd be happy to do these things, if people generally like the idea but there's not much point if they don't. Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] log options and staying on the current branch
Personally, I'd find it irritating to have the history broken off just because it went into another branch for a while... Maybe we should think about having a ~/.monotone/opts file to give the users a possibility to have their own default option values or somesuch... Either way, I'm actually writing to remind you to add something in NEWS, even though you're working in your own branch. Just to make sure it's not forgotten when the time comes to propagate this back into the main branch :-). Could you please? Cheers, Richard In message on Sun, 22 Feb 2009 19:58:45 -0700, Derek Scherger said: derek> I've often found it mildly irritating that log doesn't normally stay on the derek> current branch and that there's no nice way to specify this other than derek> something like: derek> derek> $ mtn automate select b:net.venge.monotone.library-build |mtn automate derek> toposort -...@- | xargs -n 1 mtn log --last 1 --diffs --from derek> derek> I've "fixed" this on the branch net.venge.monotone.experiment.log-options derek> which does this and a few other things: derek> derek> 1. adds --author --branch --date and --message options to log and allows derek> them all to take globs that will select interesting revisions derek> 2. since --branch is a workspace option, this has the consequence that the derek> default branch glob is the current workspace branch and so log now stays on derek> that branch by default derek> 3. logging all branches can be done by specifying --branch='' (the empty derek> branch) or --branch='*' (an inclusive glob); the former will not bother derek> attempting to match anything and will simply include any branch; the latter derek> goes through the globish machinery to achieve the same thing, in a very derek> slightly more expensive way derek> 4. changes workspace::get_options slightly, to allow --branch='' to work; derek> previously if the specified branch option was empty and the workspace branch derek> was not the workspace option was used. I think this is incorrect, if derek> --branch='' is specified on the command line then that should override derek> whatever is in the workspace derek> derek> There are a couple of failing tests with this that I still need to look into derek> but it's a pretty simple change and I think it would be very nice to have. derek> I'm curious what other people think though. derek> derek> Cheers, derek> Derek -- Richard Levitte rich...@levitte.org http://richard.levitte.org/ "Life is a tremendous celebration - and I'm invited!" -- from a friend's blog, translated from Swedish ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] log options and staying on the current branch
I've often found it mildly irritating that log doesn't normally stay on the current branch and that there's no nice way to specify this other than something like: $ mtn automate select b:net.venge.monotone.library-build |mtn automate toposort -...@- | xargs -n 1 mtn log --last 1 --diffs --from I've "fixed" this on the branch net.venge.monotone.experiment.log-options which does this and a few other things: 1. adds --author --branch --date and --message options to log and allows them all to take globs that will select interesting revisions 2. since --branch is a workspace option, this has the consequence that the default branch glob is the current workspace branch and so log now stays on that branch by default 3. logging all branches can be done by specifying --branch='' (the empty branch) or --branch='*' (an inclusive glob); the former will not bother attempting to match anything and will simply include any branch; the latter goes through the globish machinery to achieve the same thing, in a very slightly more expensive way 4. changes workspace::get_options slightly, to allow --branch='' to work; previously if the specified branch option was empty and the workspace branch was not the workspace option was used. I think this is incorrect, if --branch='' is specified on the command line then that should override whatever is in the workspace There are a couple of failing tests with this that I still need to look into but it's a pretty simple change and I think it would be very nice to have. I'm curious what other people think though. Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Mtn automate select p: Bug
On Sun, 2009-02-22 at 12:55 +0100, Thomas Keller wrote:
> Anthony Edward Cooper schrieb:
> >Hi peeps,
> >
> >Don't know if this one has been fixed already, but try doing `mtn au
> > select p:0' on the net.venge db, it doesn't like it! My db sync details
> > are:
> >
> > database: default-exclude-pattern
> > database: default-include-pattern net.venge*
> > database: default-server monotone.ca
> > known-servers: monotone.ca .
> >
> >Version on mtn is 0.42 running on a 32 bit WhiteBox 4 Respin 1 (very
> > similar to RHAS4U3).
> >
> >Did the command:
> > mtn --db=test-0.40.mtn au select p:0
> >
> >And got:
> > mtn: fatal: std::logic_error: selectors.cc:251: invariant
> > 'I(!value.empty())' violated
> > mtn: this is almost certainly a bug in monotone.
> > mtn: please send this error message, the output of 'mtn version --full',
> > mtn: and a description of what you were doing to monotone-de...@nongnu.org.
> > mtn: wrote debugging log to /home/aecoope/.monotone/dump
> > mtn: if reporting a bug, please include this file
>
> The problem is that decode_hexenc (as used in selectors.cc:196) doesn't
> cope with single digit "hex" values, they're all evaluated to an empty
> string. Try f.e. "p:9", the same invariant fires. I've stumbled upon the
> same problem in other areas before. A possible solution could be to
> "pad" uneven counts of hex values with leading zeros, i.e. "9" would be
> expanded to "09". These are then correctly processed by Botan's
> Hex_Decoder. But this is probably not what people expect, since they
> rather want that to be decoded to something like "9*".
The problem is that the selector value is being round-tripped through
{de,en}code_hexenc before going to add_prefix_matching_constraint, which
handles odd numbers of digits correctly.
It gets hex-decoded where you say, and then at database::select_parent()
it gets sent right back through encode_hexenc().
This should be fixed in e071526ac9b3f68d869dba38d365a7d3c1dee781.
--
Timothy
Free (experimental) public monotone hosting: http://mtn-host.prjek.net
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Question for Windows automate users
Timothy Brownawell writes:
> On Sun, 2009-02-15 at 10:27 -0800, Zack Weinberg wrote:
>> What's the intended effect of the make_io_binary() call in
>> automate::exec()? It looks like we're setting stdin and stdout to
>> binary mode for any automate operation, but that doesn't seem right --
>> if you're just running one automate command inside a batch file or
>> something you'd want DOS line endings, wouldn't you?
>
> get_file / get_file_of and put_file need to be binary-safe, so they work
> with binary files. stdio needs to be binary-safe, so the byte counts
> don't get messed up.
>
> The others probably don't care, but making them not binary (1) would be
> inconsistent, and (2) would mean that they'd give slightly different
> output when run through stdio. Not sure how much these points actually
> matter, especially for the commands that generate lists (tags,
> ancestors, inventory) rather than dumping items (get_current_revision).
>
> Perhaps default to binary for stdio and maybe get_file(_of)/put_file (or
> maybe not, since most files will probably be text files) and text for
> the others, with a --binary={yes|no} option to override this?
I always use editors that can deal with different line ending
conventions, so I'll never notice the difference. But it does seem
like giving the user control is a good idea.
Writing a convincing test for this will be complicated; you'll have to use
"if ostype = 'Windows'", rather than "canonicalize".
--
-- Stephe
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] mtn rename --guess
Matthew Nicholson writes: > Timothy Brownawell wrote: >> On Mon, 2009-01-26 at 22:29 -0600, Matthew Nicholson wrote: >>> Greetings, >>> >>> My rename --guess work from the mini summit is ready for testing >>> and review. It can be found in the net.venge.monotone.rename-guess >>> branch. >>> >>> The rename --guess command attempts to match files in the mtn ls >>> missing list with files in the mtn ls unknown list. Currently the >>> command will detect renames of identical files and renames of >>> directories composed of identical files. Future improvements may >>> include, renames of files and directories with partial content >>> changes. >> >> >> # >> # patch "cmd_ws_commit.cc" >> # from [f19eb71e76506b5ac8a706f610e6a34b595266a1] >> #to [b3bd3a32ee59af9edb595e9c999e937390b9965b] >> # # patch "options_list.hh" >> # from [05705dd75c2e3556f4bac136b13c802d85827e0d] >> #to [54a563f0f12bd6db64856d316d0c7a13cd0125e4] >> # # patch "work.cc" >> # from [b005a944d5e5ebcbfed43ac742871eba7d5e7ad0] >> #to [4b549d6bcb26d3e0632b08d16871195016a66e17] >> # # patch "work.hh" >> # from [cd117c8295b2bdf48db35e92aaf29842c27a1b7f] >> #to [066d38ca737363f32bfe4b4811689d09ee5066d8] >> # >> >> Should have at least one file like tests//__driver__.lua . > > Yeah, there are several cases I have thought of to test, just haven't > gotten around to writing the tests. I find it helps a lot to write at least some tests first, before starting to work on the code. This accomplishes several things: o It helps define what the code changes need to do. o It gives concrete examples when discussing the changes with others. o It gives you a defined goal; you know when you are "done". o The tests get written. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: propose to land .stripped on Tuesday
Markus Wanner writes: > Zack Weinberg wrote: >> This is the last issue I'm aware of blocking merge of .stripped to >> mainline. > > Cool, thanks. > > So, nvm.stripped is currently known to compile on at least FreeBSD and > Debian. Has anybody tried any RPM based distro recently? Or MinGW? I've tested it on MinGW; it's working. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Mtn automate select p: Bug
Anthony Edward Cooper schrieb: >Hi peeps, > >Don't know if this one has been fixed already, but try doing `mtn au > select p:0' on the net.venge db, it doesn't like it! My db sync details > are: > > database: default-exclude-pattern > database: default-include-pattern net.venge* > database: default-server monotone.ca > known-servers: monotone.ca . > >Version on mtn is 0.42 running on a 32 bit WhiteBox 4 Respin 1 (very > similar to RHAS4U3). > >Did the command: > mtn --db=test-0.40.mtn au select p:0 > >And got: > mtn: fatal: std::logic_error: selectors.cc:251: invariant > 'I(!value.empty())' violated > mtn: this is almost certainly a bug in monotone. > mtn: please send this error message, the output of 'mtn version --full', > mtn: and a description of what you were doing to monotone-de...@nongnu.org. > mtn: wrote debugging log to /home/aecoope/.monotone/dump > mtn: if reporting a bug, please include this file The problem is that decode_hexenc (as used in selectors.cc:196) doesn't cope with single digit "hex" values, they're all evaluated to an empty string. Try f.e. "p:9", the same invariant fires. I've stumbled upon the same problem in other areas before. A possible solution could be to "pad" uneven counts of hex values with leading zeros, i.e. "9" would be expanded to "09". These are then correctly processed by Botan's Hex_Decoder. But this is probably not what people expect, since they rather want that to be decoded to something like "9*". Thomas. -- GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | http://thomaskeller.biz Please note that according to the EU law on data retention, information on every electronic information exchange might be retained for a period of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Mtn automate select p: Bug
Hi peeps, Don't know if this one has been fixed already, but try doing `mtn au select p:0' on the net.venge db, it doesn't like it! My db sync details are: database: default-exclude-pattern database: default-include-pattern net.venge* database: default-server monotone.ca known-servers: monotone.ca . Version on mtn is 0.42 running on a 32 bit WhiteBox 4 Respin 1 (very similar to RHAS4U3). Did the command: mtn --db=test-0.40.mtn au select p:0 And got: mtn: fatal: std::logic_error: selectors.cc:251: invariant 'I(!value.empty())' violated mtn: this is almost certainly a bug in monotone. mtn: please send this error message, the output of 'mtn version --full', mtn: and a description of what you were doing to monotone-de...@nongnu.org. mtn: wrote debugging log to /home/aecoope/.monotone/dump mtn: if reporting a bug, please include this file mtn version --full gives: monotone 0.42 (base revision: 75ac12dd5b02025981edd6cd03caebb54721e481) Running on : Linux 2.6.9-34.ELsmp #1 SMP Sun Mar 19 13:54:02 CST 2006 i686 C++ compiler: GNU C++ version 3.4.5 20051201 (Red Hat 3.4.5-2) C++ standard library: GNU libstdc++ version 20051201 Boost version : 1_33_1 Changes since base revision: format_version "1" new_manifest [f2786e133906a73481e19a7e8d94ccaccaa977a6] old_revision [00862d40b30f11d972198ffb53e61986d3ce7aac] add_dir "tests/p_selector" add_file "tests/p_selector/__driver__.lua" content [07d038ba0783f318b8a2f0f308b230d1076e3000] patch "selectors.cc" from [42d6f2ba123ad9887a14ba28d9e6bc0a0bac5148] to [6ed76563cb3eb25fd04fa557b4a618a8f3b3ce3a] patch "work.cc" from [772e23f689e6523ca680a9dcd5d5889637eeb816] to [de879cd6058f54689874d6e06b8f23af423193ca] patch "work.hh" from [3a96efd140b80cfafff521c5c99bb187b16faed3] to [cd117c8295b2bdf48db35e92aaf29842c27a1b7f] Generated from data cached in the distribution; further changes may have been made. On older versions of mtn (0.3x) the first line of the output was blank. Cheers, Anthony. -- If at first you don't succeed... Delegate. Pay a visit to my home page at: http://www.coosoft.plus.com Current work set: 4 items - begin 'system_flavour' (in virtual void sanity::initialize(int, char**, const char*), at sanity.cc:75) Linux 2.6.9-34.ELsmp #1 SMP Sun Mar 19 13:54:02 CST 2006 i686 - end 'system_flavour' (in virtual void sanity::initialize(int, char**, const char*), at sanity.cc:75) - begin 'cmdline_string' (in virtual void sanity::initialize(int, char**, const char*), at sanity.cc:89) 'mtn', '--db=test-0.40.mtn', 'au', 'select', 'p:0' - end 'cmdline_string' (in virtual void sanity::initialize(int, char**, const char*), at sanity.cc:89) - begin 'string(lc_all)' (in virtual void sanity::initialize(int, char**, const char*), at sanity.cc:94) C - end 'string(lc_all)' (in virtual void sanity::initialize(int, char**, const char*), at sanity.cc:94) - begin 'full_version_string' (in virtual void mtn_sanity::initialize(int, char**, const char*), at mtn-sanity.cc:23) monotone 0.42 (base revision: 75ac12dd5b02025981edd6cd03caebb54721e481) Running on : Linux 2.6.9-34.ELsmp #1 SMP Sun Mar 19 13:54:02 CST 2006 i686 C++ compiler: GNU C++ version 3.4.5 20051201 (Red Hat 3.4.5-2) C++ standard library: GNU libstdc++ version 20051201 Boost version : 1_33_1 Changes since base revision: format_version "1" new_manifest [f2786e133906a73481e19a7e8d94ccaccaa977a6] old_revision [00862d40b30f11d972198ffb53e61986d3ce7aac] add_dir "tests/p_selector" add_file "tests/p_selector/__driver__.lua" content [07d038ba0783f318b8a2f0f308b230d1076e3000] patch "selectors.cc" from [42d6f2ba123ad9887a14ba28d9e6bc0a0bac5148] to [6ed76563cb3eb25fd04fa557b4a618a8f3b3ce3a] patch "work.cc" from [772e23f689e6523ca680a9dcd5d5889637eeb816] to [de879cd6058f54689874d6e06b8f23af423193ca] patch "work.hh" from [3a96efd140b80cfafff521c5c99bb187b16faed3] to [cd117c8295b2bdf48db35e92aaf29842c27a1b7f] Generated from data cached in the distribution; further changes may have been made. - end 'full_version_string' (in virtual void mtn_sanity::initialize(int, char**, const char*), at mtn-sanity.cc:23) ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
