Re: [Monotone-devel] Re: netsync connection info cleanup
Timothy Brownawell tbrow...@prjek.net writes: Hrm - should we really disallow them by default? Another option could be to just issue a warning and let the user go ahead. Wireing in the code which errors out in an invalid case and correctly rolling back might be cumbersome, given the fact that we have a couple of places from which we create branch certs (approve, commit -b, cert, automate cert, setup, import, cvs_import, ...) A warning after the fact doesn't help much, by the time you see it you've already got your hard-to-work-with branch name. Unless we want to add a 'db rename_branch_locally' or similar to make this fixable after-the-fact, and then point that out in the warning. That might actually be the better solution. This is a reasonable approach, but personally I would prefer an error (I always prefer errors over warnings; it's just too easy to miss warnings). The error can be detected as soon as the branch name is specified, so I don't see why backing out would be a problem. We have to add code in the same places to get the warning. Hmm. I guess that's not true; the warning code could be deeper in, so that could be fewer places. This is another case where it would be best to allow the user to set the default they want, but be able to override that default easily. That requires overridable options; supporting '--foo ... --no-foo'. Overridable options has come up a few times before; maybe we should make that a required feature for 1.0? I have not looked into how hard that would be. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] [bug #20711] Monotone 0.36 segfaults when inlined with gcc 3.4.6.
Follow-up Comment #4, bug #20711 (project monotone): cygwin is on gcc 4.3.4, but does not show this bug ___ Reply to this item at: http://savannah.nongnu.org/bugs/?20711 ___ Message sent via/by Savannah http://savannah.nongnu.org/ ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] [bug #20711] Monotone 0.36 segfaults when inlined with gcc 3.4.6.
Follow-up Comment #5, bug #20711 (project monotone): Well, as original reporter, I must say that I forgot about that specific compiler version long time ago (and switched to git, but that's different issue). ___ Reply to this item at: http://savannah.nongnu.org/bugs/?20711 ___ Message sent via/by Savannah http://savannah.nongnu.org/ ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: netsync connection info cleanup
Am 10.06.2010 09:49, schrieb Stephen Leake: Timothy Brownawell tbrow...@prjek.net writes: Hrm - should we really disallow them by default? Another option could be to just issue a warning and let the user go ahead. Wireing in the code which errors out in an invalid case and correctly rolling back might be cumbersome, given the fact that we have a couple of places from which we create branch certs (approve, commit -b, cert, automate cert, setup, import, cvs_import, ...) A warning after the fact doesn't help much, by the time you see it you've already got your hard-to-work-with branch name. Unless we want to add a 'db rename_branch_locally' or similar to make this fixable after-the-fact, and then point that out in the warning. That might actually be the better solution. This is a reasonable approach, but personally I would prefer an error (I always prefer errors over warnings; it's just too easy to miss warnings). See my earlier mail - how do we handle old workspaces with then invalid branch names? I don't like the idea of bailing out with an error for every workspace command just because the used branch option is wrong... This is another case where it would be best to allow the user to set the default they want, but be able to override that default easily. That requires overridable options; supporting '--foo ... --no-foo'. Overridable options has come up a few times before; maybe we should make that a required feature for 1.0? I have not looked into how hard that would be. See also my earlier mail - where do we want to draw the line? What is reasonable to expect as development outcome for the next, say, 4 weeks in June and July, where its hot everywhere...? Do we really want to block everything else until then? 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] mtn-viz
In message 20100609161751.ga16...@tenebreuse on Wed, 9 Jun 2010 18:17:51 +0200, Stéphane Gimenez d...@gim.name said: dev Hi, dev dev What's happening with mtn-viz? Which of the branches is the most dev current? I just tried nvm.monotone-viz.new-stdio, thinking that it dev should work, but can't get it to compile properly: dev dev ocamlopt.opt -I /usr/lib/ocaml/3.10.1/lablgtk2 -I glib -c glib/viz_gmisc.ml dev File glib/viz_gmisc.ml, line 4, characters 33-64: dev Error: Unbound type constructor Gtk.obj dev make: *** [glib/viz_gmisc.cmx] Fel 2 dev dev You need -dev packages or equivalent. dev On debian you need lablgtk2-ocaml-dev to compile mtn-viz. dev dev It is likely to be the cause of this compilation failure. dev dev Header files (.mli) and some source (.ml) files are needed in dev your /usr/lib/ocaml/3.10.1/lablgtk2 directory. *blush* reconfiguring resolved the problem. -- 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
Re: [Monotone-devel] mtn-viz
In message 4c0e330c.4000...@unchartedbackwaters.co.uk on Tue, 08 Jun 2010 13:09:48 +0100, Francis Russell fran...@unchartedbackwaters.co.uk said: francis Richard Levitte wrote: francis What's happening with mtn-viz? Which of the branches is the most francis current? I just tried nvm.monotone-viz.new-stdio, thinking that it francis should work, but can't get it to compile properly: francis francis The new-stdio branch is meant to be compatible with the monotone francis automate interface in 0.47. However, the code currently in the new-stdio francis branch is buggy, see francis http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574562. I was sent a francis patch by the upstream author of the new-stdio changes to fix it in francis March. It's rather concerning that the patch I was sent doesn't seem to francis be present in any monotone-viz repository, despite being copied to the francis monotone-viz developer. Also, the current release version of francis monotone-viz doesn't even contain the buggy support for 0.47. Hmmm, what are the symptoms of the buggy support? I'm running it now and I don't see any failure... Cheers, Richard -- 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
Re: [Monotone-devel] mtn-viz
Richard Levitte wrote: Hmmm, what are the symptoms of the buggy support? I'm running it now and I don't see any failure... Refreshing the graph a few times even when redrawing had completed each time, would cause the error 'Uncaught exception: Failure(mtn stdio uses an unknown format-version)'. Francis ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: netsync connection info cleanup
Thomas Keller m...@thomaskeller.biz writes: Am 10.06.2010 09:49, schrieb Stephen Leake: Timothy Brownawell tbrow...@prjek.net writes: Hrm - should we really disallow them by default? Another option could be to just issue a warning and let the user go ahead. Wireing in the code which errors out in an invalid case and correctly rolling back might be cumbersome, given the fact that we have a couple of places from which we create branch certs (approve, commit -b, cert, automate cert, setup, import, cvs_import, ...) A warning after the fact doesn't help much, by the time you see it you've already got your hard-to-work-with branch name. Unless we want to add a 'db rename_branch_locally' or similar to make this fixable after-the-fact, and then point that out in the warning. That might actually be the better solution. This is a reasonable approach, but personally I would prefer an error (I always prefer errors over warnings; it's just too easy to miss warnings). See my earlier mail - how do we handle old workspaces with then invalid branch names? I don't like the idea of bailing out with an error for every workspace command just because the used branch option is wrong... Yes; the warning or error should only occur on the creation of a new branch. This is another case where it would be best to allow the user to set the default they want, but be able to override that default easily. That requires overridable options; supporting '--foo ... --no-foo'. Overridable options has come up a few times before; maybe we should make that a required feature for 1.0? I have not looked into how hard that would be. See also my earlier mail - where do we want to draw the line? I'm suggesting we draw the line to include overridable options. But we'd have to be ok with saying this is too hard after seriously looking at it. What is reasonable to expect as development outcome for the next, say, 4 weeks in June and July, where its hot everywhere...? I don't think we should make it a time issue, as long as people are making reasonable progress on each feature we agree to hold the release for. Do we really want to block everything else until then? That's what branches are for. We could continue the current release pattern (not switch to 0.99) until all 1.0 features are ready. However, I think overrideable options is the only such feature mentioned so far? Have I missed something? And I'm not saying we must hold 1.0 for this. I think it would be good, but I'm willing to go along if the consensus is to not wait for it. Since the gnuopts package provides overridable options, lots of applications have them. So it will be perceived as a flaw that mtn doesn't. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Time for a release
Am 04.06.2010 16:26, schrieb Thomas Moschny: Am Fri, 04 Jun 2010 01:45:44 +0200 schrieb Thomas Keller m...@thomaskeller.biz: While I'm going to manage the upcoming 0.99 and 1.0.0 releases, I'd like to give my release manager hat to somebody else afterwards, so I can concentrate on other things a bit more. I'm not out of the world, so whoever wants to take the job can of course count on my help. Thanks for doing the job for a so long time now! Thank you all for being patient with me :) Doing releases does not involve much - the process is fairly good documented. Perhaps the most important skills are a bit of a passion for the software and some accuracy :) So, who's up for the job? If no one else is interested, I'd volunteer. Since nobody else spoke up over the last couple of days, you've been automatically selected ;) - thanks for taking the opportunity! 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] Re: netsync connection info cleanup
On 06/10/2010 04:45 AM, Thomas Keller wrote:
Am 10.06.2010 05:02, schrieb Timothy Brownawell:
What sort of other things, more user-visible changes or internal code
hygiene?
Both, actually:
* cleanup the connection info handling mess
* remove the code for the other include / exclude variants with
include= and exclude=
* discourage branch names which conflict the new uri scheme as discussed
either with a warning or an error
* let clone accept mtn:// uris
* deprecate SERVER [BRANCH [--exclude=PATTERN [...]]] arguments to push
/ pull / sync - I'd then include code to fall back on already existing
branch patterns if f.e. a user only enters mtn://some.server instead of
mtn://some.server?some.branch
We have automate {push,pull,sync} now, so the second and last items
would I think be incompatible automate changes and therefore a major
version change. And releasing 2.0 very soon after 1.0 would probably get
people to look at us funny...
Right now mtn:// sync doesn't work at all, and it really would
be nice for 1.0 to support non-hacky virtual hosting without needing a
special DNS setup.
I'm a little torn between theee options here - release an unplanned 0.48
in the meantime to no longer block finished things and get your work
into trunk before we hit 0.99, let 0.99 wait until the above work has
been finished and just following the planned path and get the work into 1.1.
I don't want to change the plan too often. What if other people suddenly
want to get a certain thing done before the glorious 1.0 hits the
street? Where do I stop? Opinions anybody?
To not mess too much with the masterplan I tend to wait for 0.99 a
little longer...
What *breaking* (ie, major-version change; automate major number bump or
non-negotiable network incompatibility) changes do we have that can
reasonably be expected to be ready in less than, say, 2 months? (Any
major-version changes not ready in time would have to wait... probably
at least a year, in the absence of any brown-paper-bag design bugs.
Minor-version changes can of course happen whenever.)
- getting rid of SERVER [PATTERN ... [--exclude=PATTERN ...]]
- this is a breaking change, and should be doable in that time
- get rid of long-form include=... exclude=... syntax for uri syncs
- breaking change; doable in 2 months
?? fixing mtn:// sync; passing 'path' info to usher
- not really a breaking change; but releasing 1.0 without this
would be expected to reduce hosting choices/quality for as
long as 1.0 stays in general use. This is ready now.
- extended selectors
- not a breaking change? (actually I guess it is; you need to escape
some additional rarely-used characters). This is ready now.
- deprecating some branch names
- there is no automate commit, but at least the error version
would probably mean changing the behavior of automate cert
and I'm not sure if the warning version would count as a change.
But as noted below I think now that this is silly and we probably
don't want to bother with it. If we do do this, it's doable
in 2 months.
* policy branches
- not even close to 2 months, more like a year or year and a half
* daggy refinement
- can be made compatible; not really started so longer than 2 months
* SSL for netsync
- can be made compatible; also not really started, so longer
than 2 months
* rename --guess (I think there's a branch out there for this)
- not a breaking change
* partial pull
- not started, way more than 2 months; wouldn't be a breaking change
in that fallback to an older netsync version is possible (but
partial pulls would only work with a recent enough server)
* get rid of die-die-die
- this would probalby require change the revision format, so it would
be a breaking change; but it's way longer than 2 months
* 'mountpoint' node type to replace merge_into_dir
- this would definitely require changing the revision format, and
would definitely take longer than 2 months
* a way to remove illegal files from history
- requires cooperation between client and server, would be a breaking
change; way longer than 2 months
* netsync preview
- not a breaking change; depending on what's in the preview it likely
wouldn't even affect the wire protocol at all
A warning after the fact doesn't help much, by the time you see it
you've already got your hard-to-work-with branch name. Unless we want to
add a 'db rename_branch_locally' or similar to make this fixable
after-the-fact, and then point that out in the warning. That might
actually be the better solution.
I'm still up for a warning - what if you have a checked out workspace
and upgrade to the mtn version which disallows its particular naming?
You won't be able to do a single commit any longer.
That would be handled by permitting any branch name that already exists.
...really, this whole thing is a bit silly. Nobody actually uses funny
characters in their branch
Re: [Monotone-devel] Re: netsync connection info cleanup
Am 10.06.10 18:48, schrieb Timothy Brownawell:
On 06/10/2010 04:45 AM, Thomas Keller wrote:
Am 10.06.2010 05:02, schrieb Timothy Brownawell:
What sort of other things, more user-visible changes or internal code
hygiene?
Both, actually:
* cleanup the connection info handling mess
* remove the code for the other include / exclude variants with
include= and exclude=
* discourage branch names which conflict the new uri scheme as discussed
either with a warning or an error
* let clone accept mtn:// uris
* deprecate SERVER [BRANCH [--exclude=PATTERN [...]]] arguments to push
/ pull / sync - I'd then include code to fall back on already existing
branch patterns if f.e. a user only enters mtn://some.server instead of
mtn://some.server?some.branch
We have automate {push,pull,sync} now, so the second and last items
would I think be incompatible automate changes and therefore a major
version change. And releasing 2.0 very soon after 1.0 would probably get
people to look at us funny...
Right, thats why I'd just deprecate them - i.e. they are still fully
workable, but we say we remove that in 2.0 and we're using the URIs
everywhere, in the documentation, in the wiki, etc. pp. This kind of
deprecation should have no visible effect in the UI nor in automate.
Right now mtn:// sync doesn't work at all, and it really would
be nice for 1.0 to support non-hacky virtual hosting without needing a
special DNS setup.
I'm a little torn between theee options here - release an unplanned 0.48
in the meantime to no longer block finished things and get your work
into trunk before we hit 0.99, let 0.99 wait until the above work has
been finished and just following the planned path and get the work
into 1.1.
I don't want to change the plan too often. What if other people suddenly
want to get a certain thing done before the glorious 1.0 hits the
street? Where do I stop? Opinions anybody?
To not mess too much with the masterplan I tend to wait for 0.99 a
little longer...
What *breaking* (ie, major-version change; automate major number bump or
non-negotiable network incompatibility) changes do we have that can
reasonably be expected to be ready in less than, say, 2 months? (Any
major-version changes not ready in time would have to wait... probably
at least a year, in the absence of any brown-paper-bag design bugs.
Minor-version changes can of course happen whenever.)
- getting rid of SERVER [PATTERN ... [--exclude=PATTERN ...]]
- this is a breaking change, and should be doable in that time
- get rid of long-form include=... exclude=... syntax for uri syncs
- breaking change; doable in 2 months
?? fixing mtn:// sync; passing 'path' info to usher
- not really a breaking change; but releasing 1.0 without this
would be expected to reduce hosting choices/quality for as
long as 1.0 stays in general use. This is ready now.
- extended selectors
- not a breaking change? (actually I guess it is; you need to escape
some additional rarely-used characters). This is ready now.
- deprecating some branch names
- there is no automate commit, but at least the error version
would probably mean changing the behavior of automate cert
and I'm not sure if the warning version would count as a change.
But as noted below I think now that this is silly and we probably
don't want to bother with it. If we do do this, it's doable
in 2 months.
* policy branches
- not even close to 2 months, more like a year or year and a half
* daggy refinement
- can be made compatible; not really started so longer than 2 months
* SSL for netsync
- can be made compatible; also not really started, so longer
than 2 months
* rename --guess (I think there's a branch out there for this)
- not a breaking change
* partial pull
- not started, way more than 2 months; wouldn't be a breaking change
in that fallback to an older netsync version is possible (but
partial pulls would only work with a recent enough server)
* get rid of die-die-die
- this would probalby require change the revision format, so it would
be a breaking change; but it's way longer than 2 months
* 'mountpoint' node type to replace merge_into_dir
- this would definitely require changing the revision format, and
would definitely take longer than 2 months
* a way to remove illegal files from history
- requires cooperation between client and server, would be a breaking
change; way longer than 2 months
* netsync preview
- not a breaking change; depending on what's in the preview it likely
wouldn't even affect the wire protocol at all
Nice list - is this directly from your personal todo...? :)
I won't comment on each single one - just two things:
1) We don't care about free-text out-of-band output, so if some command
issues a warning or a progress message more than before or differently,
no whatsoever version bump
[Monotone-devel] [bug #30110] mtn status fails by default with multiple keys
URL: http://savannah.nongnu.org/bugs/?30110 Summary: mtn status fails by default with multiple keys Project: monotone Submitted by: tommyd Submitted on: Do 10 Jun 2010 23:30:25 CEST Category: command line UI Severity: 3 - Normal Item Group: incorrect behavior Status: None Privacy: Public Assigned to: None Open/Closed: Open Discussion Lock: Any mtn version --full: mtn 0.48dev ___ Details: Tim reports on IRC: $ mtn st mtn: misuse: you have multiple private keys mtn: misuse: pick one to use for signatures by adding '-kkeyname' to your command I can see it needs to know the key to get at what the author cert would be, but that still seems a rather odd effect. ___ Reply to this item at: http://savannah.nongnu.org/bugs/?30110 ___ 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] Re: netsync connection info cleanup
On 06/10/2010 02:36 PM, Thomas Keller wrote:
Am 10.06.10 18:48, schrieb Timothy Brownawell:
On 06/10/2010 04:45 AM, Thomas Keller wrote:
Am 10.06.2010 05:02, schrieb Timothy Brownawell:
What sort of other things, more user-visible changes or internal code
hygiene?
Both, actually:
* cleanup the connection info handling mess
* remove the code for the other include / exclude variants with
include= and exclude=
* discourage branch names which conflict the new uri scheme as discussed
either with a warning or an error
* let clone accept mtn:// uris
* deprecate SERVER [BRANCH [--exclude=PATTERN [...]]] arguments to push
/ pull / sync - I'd then include code to fall back on already existing
branch patterns if f.e. a user only enters mtn://some.server instead of
mtn://some.server?some.branch
We have automate {push,pull,sync} now, so the second and last items
would I think be incompatible automate changes and therefore a major
version change. And releasing 2.0 very soon after 1.0 would probably get
people to look at us funny...
Right, thats why I'd just deprecate them - i.e. they are still fully
workable, but we say we remove that in 2.0 and we're using the URIs
everywhere, in the documentation, in the wiki, etc. pp. This kind of
deprecation should have no visible effect in the UI nor in automate.
OK, that makes sense.
Right now mtn:// sync doesn't work at all, and it really would
be nice for 1.0 to support non-hacky virtual hosting without needing a
special DNS setup.
I'm a little torn between theee options here - release an unplanned 0.48
in the meantime to no longer block finished things and get your work
into trunk before we hit 0.99, let 0.99 wait until the above work has
been finished and just following the planned path and get the work
into 1.1.
I don't want to change the plan too often. What if other people suddenly
want to get a certain thing done before the glorious 1.0 hits the
street? Where do I stop? Opinions anybody?
To not mess too much with the masterplan I tend to wait for 0.99 a
little longer...
What *breaking* (ie, major-version change; automate major number bump or
non-negotiable network incompatibility) changes do we have that can
reasonably be expected to be ready in less than, say, 2 months? (Any
major-version changes not ready in time would have to wait... probably
at least a year, in the absence of any brown-paper-bag design bugs.
Minor-version changes can of course happen whenever.)
- getting rid of SERVER [PATTERN ... [--exclude=PATTERN ...]]
- this is a breaking change, and should be doable in that time
- get rid of long-form include=... exclude=... syntax for uri syncs
- breaking change; doable in 2 months
So these two are non-breaking due to being just a deprecation instead of
removal.
?? fixing mtn:// sync; passing 'path' info to usher
- not really a breaking change; but releasing 1.0 without this
would be expected to reduce hosting choices/quality for as
long as 1.0 stays in general use. This is ready now.
- extended selectors
- not a breaking change? (actually I guess it is; you need to escape
some additional rarely-used characters). This is ready now.
- deprecating some branch names
- there is no automate commit, but at least the error version
would probably mean changing the behavior of automate cert
and I'm not sure if the warning version would count as a change.
But as noted below I think now that this is silly and we probably
don't want to bother with it. If we do do this, it's doable
in 2 months.
Nice list - is this directly from your personal todo...? :)
Some of the things are, but I also checked the wiki and current branches
and Pidgin's monotone limitations page.
I won't comment on each single one - just two things:
1) We don't care about free-text out-of-band output, so if some command
issues a warning or a progress message more than before or differently,
no whatsoever version bump should be introduced. This is not because
we're all lazy, but because this wouldn't be managable at all (imagine
an string fix deep in the code path which is executed by a normal and an
automate command).
Makes sense.
2) I acknowledge that a couple of people seem to be somewhat overrun by
the whole 1.0 discussion - and I'm almost convinced to release a 0.48
within the next few days and skip the 1.0 plans until the majority of
people (i.e. not just me apparently, I don't get much positive
feedback...) have a good feeling about it. Could we then at least have
some terminated goal, f.e. early this fall, to make 1.0 finally arrive then?
I'd like to see what other breaking changes people have in mind, that
can be done reasonably soon. Say we take through this weekend to collect
all breaking changes that can hit some deadline (2 months, or the end of
September, or something), and then do 1.0 at the deadline or earlier if
everything on the list is in.
It looks like we probably do
Re: [Monotone-devel] usher
On 06/09/2010 07:21 AM, Thomas Keller wrote: Am 17.04.2010 17:39, schrieb Timothy Brownawell: On 04/15/2010 02:13 AM, Thomas Keller wrote: Let's concentrate first to put usher in a release-capable state so packagers (like me :) can pick it up. If it packaged I'll have a much easier way to convince the guys over there at indefero some time to install and configure it as monotone helper for the use case. Seems reasonable. Hi Tim! Do you have this still on your schedule somewhere...? Is there anything I could help you out with? Thomas. I got it so that 'make distcheck' works, so I suppose the only things left are making sure it works on *bsd, and then properly documenting which monotone client version is required for explicit server names to work (right now it's documented as 0.48). -- Timothy Free public monotone hosting: http://mtn-host.prjek.net ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
