[Monotone-devel] [bug #30345] Key management over automate

[Thomas Keller]

Follow-up Comment #2, bug #30345 (project monotone):

Interesting, totally forgot about read_packets indeed. Probably because I
thought this is only able to consume packets the other packet functions can
spit out...

You're right that removing public keys might cause issues when the key signed
stuff and the key is likely to come back anyways when another node uses
--key-to-push to upload it again, but I thought of it as a mental model from
an interface point of view, i.e. you can list something, can add something new
and you can also undo the previous action and remove something which you
accidentially added. Maybe mtn au dropkey could check if the key signed
anything and error out in this case?

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.nongnu.org/


___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

[Monotone-devel] [bug #30345] Key management over automate

[Thomas Keller]

Follow-up Comment #3, bug #30345 (project monotone):

I forgot one thing - given the fact that we want to deprecate / remove the
packet functions (at least for revisions, certs, files and file deltas) on the
long run, we _might_ not want to use read_packets for put_public_key.

The removal of the packet functions is on the roadmap for a long time - I
don't know if people still use these functions at all.

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.nongnu.org/


___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] automate log

[Stephen Leake]

Thomas Keller  writes:

> A few objections:
>
> 1) in monotone.texi / cmd_diff_log.cc:
>
>   +[--la...@var{n}] [--ne...@var{n}] [--fr...@var{id} [...]]
>   +[--...@var{id} [...]] [--no-merges] [--no-files]
>
>   If only revision ids are outputted, the --no-files option is bogus

Ah. From the description, I assumed it was a rev filter, the opposite of
--no-merges. But looking at the code, I see it means "no revision
summary".

> 2) in monotone.texi:
>
>   +These messages are in the 'm' stream in automate stdio.
>
>   All the normal output for every automate command goes to this stream.
>   Since we do not mention it anywhere else explicitely, we shouldn't do
>   that here either.

Ok.

> 3) in cmd_diff_log.cc:
>
>   +void
>   +log_print_rev (app_state &  app,
>   +   database &   db,
>   +   project_t &  project,
>   +   revision_id  rid,
>   +   revision_t & rev,
>   +   string   date_fmt,
>   +   node_restriction mask,
>   +   bool automate,
> 
>
>   Please use an enum for this and later uses.

I prefer a bool, for a couple reasons:

- I'm not clear what the other name should be (note your example below
  doesn't give one). "automate" and "not automate" are clear in this
  context.

- When there's an enum, I have to wonder how many choices there are, so
  case statements are required. That seems overkill for two choices.
  Your example uses an 'if', so a bool is more appropriate.

There are certainly many other places in mtn that use bool for similar
choices.

>   Also, because log_print_rev is only used twice and the use is
>   determined with this
>
>   if (automate)
> log_print_rev (app, db, project, rid, rev, date_fmt, mask, \
>automate, output);
>   else
> ostringstream out;
> log_print_rev (app, db, project, rid, rev, date_fmt, mask, \
>automate, out);
>
>   The code could be simplified like this:
>
>   if (target == automate_log)
> out << rid << "\n";
>   else
> {
>// the former code which prints everything else ...
> }

Yes, that is cleaner. But I'll keep log_print_rev for the else branch;
that makes it easier to see the logic flow. Comparing either version to
main requires telling ediff to focus on regions.

> 4) You have quite a lot whitespace changes

The only way to fully eliminate whitespace changes is for every file to
follow a standard convention. I have emacs set to enforce what I
perceive to be the monotone convention, so it fixes files that I edit.

It's easy to ignore whitespace changes in a good diff tool, so I don't
see this as a problem.

> / unrelated changes e.g. in testlib.lua and a couple of others. Some
> of them seem to be needed for your current work,

That was to help with debugging this test. The commit log gives a clear
explanation.

> but in general please try to keep the patch at a minimum and commit
> unrelated things directly to mainline next time.

Ok, I'll keep that in mind.

Thanks for your review. Changes synced.

--
-- Stephe

___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] automate log

[Thomas Keller]

Am 06.07.2010 09:28, schrieb Stephen Leake:
> Thomas Keller  writes:
>> 3) in cmd_diff_log.cc:
>>
>>   +void
>>   +log_print_rev (app_state &  app,
>>   +   database &   db,
>>   +   project_t &  project,
>>   +   revision_id  rid,
>>   +   revision_t & rev,
>>   +   string   date_fmt,
>>   +   node_restriction mask,
>>   +   bool automate,
>>
>>
>>   Please use an enum for this and later uses.
> 
> I prefer a bool, for a couple reasons:
> 
> - I'm not clear what the other name should be (note your example below
>   doesn't give one). "automate" and "not automate" are clear in this
>   context.

Just because I didn't give you the other option, this shouldn't hold you
off finding a good name - f.e. "user_log".

The reason why I (and I think a couple of other people here as well)
hate boolean function arguments with a passion is that they make it
harder to understand what the meaning of the function argument actually
is. This gets extra hard if there is not just one, but a couple of
boolean function arguments - and since you can't force people to write

  bool first_arg = true, second_arg = false;
  my_func_call(first_arg, second_arg);

- which looks a little stupid to me anyways - its better to use an enum
value right away.

> - When there's an enum, I have to wonder how many choices there are, so
>   case statements are required. That seems overkill for two choices.
>   Your example uses an 'if', so a bool is more appropriate.

It makes the code much more describable.

> There are certainly many other places in mtn that use bool for similar
> choices.

Yes, unfortunately, and my mission is to change this in the future :)

>>   Also, because log_print_rev is only used twice and the use is
>>   determined with this
>>
>>   if (automate)
>> log_print_rev (app, db, project, rid, rev, date_fmt, mask, \
>>automate, output);
>>   else
>> ostringstream out;
>> log_print_rev (app, db, project, rid, rev, date_fmt, mask, \
>>automate, out);
>>
>>   The code could be simplified like this:
>>
>>   if (target == automate_log)
>> out << rid << "\n";
>>   else
>> {
>>// the former code which prints everything else ...
>> }
> 
> Yes, that is cleaner. But I'll keep log_print_rev for the else branch;
> that makes it easier to see the logic flow. Comparing either version to
> main requires telling ediff to focus on regions.

Ok.

>> 4) You have quite a lot whitespace changes
> 
> The only way to fully eliminate whitespace changes is for every file to
> follow a standard convention. I have emacs set to enforce what I
> perceive to be the monotone convention, so it fixes files that I edit.
> 
> It's easy to ignore whitespace changes in a good diff tool, so I don't
> see this as a problem.

Yes, this is not a strong objection, I tend to fix whitespaces
"on-the-run" as well, so I shouldn't throw around bricks in the glass
house :), but still, unless someone comes around and implements
--no-whitespace in mtn diff, we should still take a little care of that.

> Thanks for your review. Changes synced.

Thanks for your work.

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

Re: [Monotone-devel] automate log

[Stephen Leake]

Thomas Keller  writes:

> Am 06.07.2010 09:28, schrieb Stephen Leake:
>> Thomas Keller  writes:
>>> 3) in cmd_diff_log.cc:
>>>
>>>   +void
>>>   +log_print_rev (app_state &  app,
>>>   +   database &   db,
>>>   +   project_t &  project,
>>>   +   revision_id  rid,
>>>   +   revision_t & rev,
>>>   +   string   date_fmt,
>>>   +   node_restriction mask,
>>>   +   bool automate,
>>>   
>>>
>>>   Please use an enum for this and later uses.
>> 
>> I prefer a bool, for a couple reasons:
>> 
>> - I'm not clear what the other name should be (note your example below
>>   doesn't give one). "automate" and "not automate" are clear in this
>>   context.
>
> Just because I didn't give you the other option, this shouldn't hold you
> off finding a good name - f.e. "user_log".

I find "bool automate" to be perfectly clear. Finding another name for
the other option is a waste of time and energy (admittedly not a big waste).

"user_log" would be very bad; it should be a name that means the same
thing in all other automate/user commands, since they will (in general)
need this same option. Finding _good_ names is not easy!

See? We've already wasted more time than it's worth :).

> The reason why I (and I think a couple of other people here as well)
> hate boolean function arguments with a passion is that they make it
> harder to understand what the meaning of the function argument actually
> is. 

Yes. You have to go look at the function spec to find the name of the
argument. That's what named association is for in more modern languages. 

It doesn't help that g++ doesn't output decent cross referencing info,
so Emacs can't jump to the spec automatically.

The Gnu Ada compiler does output cross references; that's two reasons to
prefer Ada :).

> This gets extra hard if there is not just one, but a couple of boolean
> function arguments - and since you can't force people to write
>
>   bool first_arg = true, second_arg = false;
>   my_func_call(first_arg, second_arg);
>
> - which looks a little stupid to me anyways - its better to use an enum
> value right away.

With more realistic names instead of 'first_arg', 'second_arg', this
would look better.

This issue is not limited to bool; any time there are several args of the
same type, confusion is likely. 

With Ada named association, this call would be:

my_func_call(first_arg => true, second_arg => false);
 
I try to use this commenting style to label the args when there is more
than one of the same type:

my_func_call(true,   // first_arg
 false); // second_arg

I could do the same for single bool args; that would be ok.

So I see your proposed use of an enum type as a workaround for the lack
of named association in C++. In general, I hate workarounds like this; I
prefer to expose the problems as part of advocating for better language.
But I'm really not proposing to rewrite mtn in Ada :).

But I do prefer my commenting style workaround to using enums instead of
bools; it's more general, and saves the effort of making up names.

>> - When there's an enum, I have to wonder how many choices there are, so
>>   case statements are required. That seems overkill for two choices.
>>   Your example uses an 'if', so a bool is more appropriate.
>
> It makes the code much more describable.

Apparently we disagree on this. Can you give an example of describing
this code? Here's one:

The 'automate' flag controls what is output; when true, only the
revision id is output. When false, the author, date, and changelog
are output; the non-automate output is further controlled by other
options. 

Using 'target' and 'user_log':

The 'target' flag controls what is output; when 'automate', only the
revision id is output. When 'user_log', the author, date, and changelog
are output; the non-automate output is further controlled by other
options. 

I find the first more understandable (but not by much). In the second, I
have to wonder what 'target' means, and why the non-automate version
seems to be specific to 'log', rather than general to all non-automate
commands.


Perhaps 'bool automate_p' would be better? Where '_p' means 'predicate'?
That's a common convention in lisp code.

>> There are certainly many other places in mtn that use bool for similar
>> choices.
>
> Yes, unfortunately, and my mission is to change this in the future :)

Sometimes I like tilting at windmills, too :).

I'll merge this to main soon.

Thanks again.

-- 
-- Stephe

___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] automate log

[Thomas Keller]

Am 06.07.2010 10:15, schrieb Stephen Leake:
> Thomas Keller  writes:
>> Am 06.07.2010 09:28, schrieb Stephen Leake:
>>> I prefer a bool, for a couple reasons:
>>>
>>> - I'm not clear what the other name should be (note your example below
>>>   doesn't give one). "automate" and "not automate" are clear in this
>>>   context.
>>
>> Just because I didn't give you the other option, this shouldn't hold you
>> off finding a good name - f.e. "user_log".
> 
> I find "bool automate" to be perfectly clear. Finding another name for
> the other option is a waste of time and energy (admittedly not a big waste).
> [snip]

Lets stop painting the bikeshed. I won't hold you off using bools in
your code and you won't hold me off using enums in my code, ok? :-)
I try to remember this discussion for the next review and avoid comments
on this issue...

> I'll merge this to main soon.

Yep, do so please.

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

Re: [Monotone-devel] WIP: multirevision disapprove

[Tero Koskinen]

Hi,

One more update to this.

Revisions can be found from stronglytyped.org (branch
nvm.tkoskine.disapprove-multirev) as usual.

The latest revision is ab0d1c7f1e09e5b0edd1779272e9d191c546bfb1.

The diff between h:net.venge.monotone and
h:net.venge.monotone.tkoskine.disapprove-multirev is also
attached.

On Tue, 29 Jun 2010 00:16:57 +0200 Thomas Keller wrote:
> Am 28.06.10 22:45, schrieb Tero Koskinen:
> >>> At the moment the server carries three branches:
> >>> net.venge.monotone.tkoskine.disapprove-multirev
> > 
> > I updated nvm.tkoskine.disapprove-multirev branch at stronglytyped.org
> > server. The branch now contains code, some tests, and a small documentation
> > change.
> 
> The docs now say
> 
> > -...@item mtn disapprove @var{id}
> > +...@item mtn disapprove [...@var{parent}] @var{child}
> 
> while the command says
> 
> > Syntax specific to 'mtn disapprove':
> > 
> >   disapprove REVISION [REVISION]

I changed the command to say:
  disapprove [PARENT-REVISION] CHILD-REVISION

> > +check(get("badfile", "testfile"))
> 
> A small tip: Instead of pulling predefined files with dummy contents
> from the test directory, it might be easier to just use
> 
> addfile("goodfile", "dummy content")

I changed this for one simple case. In other places I still use
get(a,b), since personally I found it easier to follow the testcases
when file contents are in separate files.

> Maybe I'm just a little picky, but my original "miuse case" was:
> 
>   $ mtn disapprove h:BRANCH1 h:BRANCH2
> 
> whereas I imagined a message like
> 
>   mtn: misuse: the revision REV1 and REV2 do not share common history

Error messages are now following:

$ mtn disapprove  h:net.venge.monotone-viz h:net.venge.monotone
mtn: expanding selection 'h:net.venge.monotone-viz'
mtn: expanded to '78a87d334b15645b2bb54afec96ac5d3e1e45350'
mtn: expanding selection 'h:net.venge.monotone'
mtn: expanded to '7b3a6be6ed783be2973ee26f5ecf9fd85d67a8af'
mtn: misuse: revisions 78a87d334b15645b2bb54afec96ac5d3e1e45350 and 
7b3a6be6ed783be2973ee26f5ecf9fd85d67a8af do not share common history, cannot 
invert

$ mtn disapprove h:net.venge.monotone.tkoskine.disapprove-multirev 
h:net.venge.monotone.stephe
mtn: expanding selection 'h:net.venge.monotone.tkoskine.disapprove-multirev'
mtn: expanded to 'ab0d1c7f1e09e5b0edd1779272e9d191c546bfb1'
mtn: expanding selection 'h:net.venge.monotone.stephe'
mtn: expanded to 'b35648df22273258b77f58db9d2f767cad0d3698'
mtn: misuse: revisions share common history, but 
ab0d1c7f1e09e5b0edd1779272e9d191c546bfb1 is not an ancestor of 
b35648df22273258b77f58db9d2f767cad0d3698, cannot invert

> Thomas.

-- 
Tero Koskinen 


monotone-disapprove-v3.diff
Description: Binary data
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

[Monotone-devel] Possible bug in `mtn log`?

[Marcin W. Dąbrowski]

Hi.

Today I hit something weird, when trying to see the history of one
of the files in my repository - `mtn log filename.ext` is showing
logs for other files than 'filename.ext'.

I tried to find minimal case, and running the sequence you can see
presented below hits the "bug" - or to say this in other words —
it shows not exactly the information I'd like to see.

#v+
mtn -d mtn.mtn db init
mtn -d mtn.mtn setup . -b mtn.bug.log

echo x> example.txt
mtn add example.txt
mtn ci -m "Added new file."

mkdir sec
cd sec
mtn -d ../mtn.mtn setup . -b mtn.bug.sec

echo y> second.txt
mtn add second.txt
mtn ci -m "Added new file, second branch." -b mtn.bug.sec

cd ..
mtn up -r h: -b mtn.bug.log
rm -rf sec
mtn merge_into_dir --update -m "merge_into_dir src" mtn.bug.sec
mtn.bug.log sec

cd sec
mtn log --no-merges second.txt
#v-

I see two changelogs printed. I don't know why I see the changelog
for example.txt, nor why the order is chronological (normally it
should be reverse chronology - usually it is).

So - is this by design (no, really?), or a bug?

PS:  mtn version --full gives
monotone 0.48 (base revision:
844268c137aaa783aa800a9c16ae61edda80ecea)
Running on  : Windows NT/2000/XP/2003 (5.1, build 2600,
Service Pack 3) on ia32 (level 6, rev 3846)

Sincerely,
-- 
Marcin W. Dabrowski


___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] net.venge.monotone-viz.net-stdio

[Thomas Moschny]

Hi all,

Francis Russell :

> Hi Stéphane,
> 
> a while back you sent me a patch against revision
> 142b487d0b2cc5e24e17998407f7921f2372ea3c in the new-stdio branch of
> monotone-viz to fix a parsing bug. I was wondering if this patch was
> available anywhere in a monotone revision? Ideally, it would be nice
> if it was available as part of the new-stdio branch on monotone.ca.
> I'm looking to get the Debian monotone-viz package working again and
> it would be nice if I could simply point to a commit on the new-stdio
> branch as the source of my patch.

Committed as b34ff2e695b53c2d73d533a3ffa7cb081b48eefb on branch
net.venge.monotone-viz.new-stdio.

Regards,
Thomas

-- 
Thomas Moschny  

___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] monotone-viz workaround for a bug in recent graphvizs

[Thomas Moschny]

Hi Olivier,

this patch seems to work fine here, and I'd like to commit it on
nvm.monotone-viz. Any objections?

Regards,
Thomas


Stéphane Gimenez :

> Hi monotoners,
> 
> Quoting debian bug #563634, you may have found revisions nodes
> "displaced with respect to the edges connecting them" in monotone-viz
> display.
> 
> In fact, dot's "-y" option appears to be broken recently.
> An alternative is to use "rankdir=BT".
> It is more natural and hopefully solves the issue.
> 
> Here's a patch for monotone-viz.
> 
> Stéphane


-- 
Thomas Moschny  

___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] WIP: multirevision disapprove

[Thomas Keller]

Am 06.07.10 15:34, schrieb Tero Koskinen:
> Hi,
> 
> One more update to this.
> 
> Revisions can be found from stronglytyped.org (branch
> nvm.tkoskine.disapprove-multirev) as usual.
> 
> The latest revision is ab0d1c7f1e09e5b0edd1779272e9d191c546bfb1.
> 
> The diff between h:net.venge.monotone and
> h:net.venge.monotone.tkoskine.disapprove-multirev is also
> attached.

All fine. Pulled, merged and pushed as
4ac132aed7e817529fc9a281a519a3964ad13c64.

Thanks for your work!
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

Re: [Monotone-devel] Possible bug in `mtn log`?

[Thomas Keller]

Am 06.07.10 19:15, schrieb "Marcin W. Dąbrowski":
> Hi.
> 
> Today I hit something weird, when trying to see the history of one
> of the files in my repository - `mtn log filename.ext` is showing
> logs for other files than 'filename.ext'.
> 
> I tried to find minimal case, and running the sequence you can see
> presented below hits the "bug" - or to say this in other words —
> it shows not exactly the information I'd like to see.
> [snip]
> I see two changelogs printed. I don't know why I see the changelog
> for example.txt, nor why the order is chronological (normally it
> should be reverse chronology - usually it is).
> 
> So - is this by design (no, really?), or a bug?

I think this is a fall-out of the new restrictions code which landed in
0.48 (try out 0.47 and you see the expected behaviour). We now
implicitely include all parents of a node in a restriction and as such,
if you log "sec/second.txt", changes for "sec" and "" (the root node)
are also logged.

I'll try out a fix and switch the restriction handling mode to what we
use also for 'revert', i.e. no implicit includes.

Stay tuned and thanks for the report,
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

Re: [Monotone-devel] Possible bug in `mtn log`?

[Thomas Keller]

Am 06.07.10 23:10, schrieb Thomas Keller:
> Am 06.07.10 19:15, schrieb "Marcin W. Dąbrowski":
>> Hi.
>>
>> Today I hit something weird, when trying to see the history of one
>> of the files in my repository - `mtn log filename.ext` is showing
>> logs for other files than 'filename.ext'.
>>
>> I tried to find minimal case, and running the sequence you can see
>> presented below hits the "bug" - or to say this in other words —
>> it shows not exactly the information I'd like to see.
>> [snip]
>> I see two changelogs printed. I don't know why I see the changelog
>> for example.txt, nor why the order is chronological (normally it
>> should be reverse chronology - usually it is).
>>
>> So - is this by design (no, really?), or a bug?
> 
> I think this is a fall-out of the new restrictions code which landed in
> 0.48 (try out 0.47 and you see the expected behaviour). We now
> implicitely include all parents of a node in a restriction and as such,
> if you log "sec/second.txt", changes for "sec" and "" (the root node)
> are also logged.
> 
> I'll try out a fix and switch the restriction handling mode to what we
> use also for 'revert', i.e. no implicit includes.

I committed a temporary fix in branch
net.venge.monotone.restriction-fixes, but this is not ready for mainline
yet, because it breaks one test, namely log_--diffs.

The underlying problem here is that we use the initial node restriction
mask for two distinct things, for one to filter out unwanted revisions
from log's display and on the other hand to create a restricted roster
to iterate over when the --diffs option is supplied. The creation of the
latter roster fails now though, because the parent nodes are no longer
part of the node restriction.

From my simple viewpoint the "fix" I see for this issue is to create
another node restriction mask, exclusively for --diffs and build that
with implicit_includes, but this sounds a little awkward to me and I
wanted to hear opinions from others, namely Derek who invented all this
magic :), before I do stupid things...

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

Re: [Monotone-devel] monotone-viz workaround for a bug in recent graphvizs

[Francis Russell]

Thomas Moschny wrote:

> this patch seems to work fine here, and I'd like to commit it on
> nvm.monotone-viz. Any objections?

Just one thing, is there any particular reason why the patch changes the
  shell dot runs under to bash?

Also, if you do decide to commit it, could you please propagate to the
new-stdio branch as well?

Francis

___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel