On Tue, Apr 6, 2021 at 12:05 AM Lapo Luchini wrote:
> On 2021-04-06 01:13, grarpamp wrote:
> >> I know the project is being still for a long time, but I think an 1.2
> >> release that officially supports Botan2 would be in order
> >
> > Put the monotone project up on github, all of the...
> >
It's nice to hear that the exporter is working for people.
Cheers,
Derek
On Fri, Nov 23, 2018 at 8:30 AM Lapo Luchini wrote:
> Stephen Leake wrote:
> >>> A better option with monotone and git is to export the monotone db to a
> >>> git repository. I have not done this yet, but others have
I have a slightly older export here as well
https://github.com/dscherger/monotone but I'm not keeping it up to date.
both have been exported via the git export feature. The problem with
> that is: incremental updates are not supported.
>
I'm not entirely sure this is true, I haven't looked at
On Fri, Sep 10, 2010 at 3:11 PM, Francis Russell
fran...@unchartedbackwaters.co.uk wrote:
Stephen Leake wrote:
The first draft is now pushed. I think it does everything everyone asked
for; give it a try.
Hi,
I took a quick look and it's certainly an improvement over the previous
On Sun, Sep 5, 2010 at 1:37 AM, Stephen Leake
stephen_le...@stephe-leake.org wrote:
There was discussion of whitespace trimming; with this format, only
trailing blank lines need to be trimmed from the commit comment.
Possibly a hook to do user controllable message cleanup might be good,
2010/8/14 Timothy Brownawell tbrow...@prjek.net
This is changed now. --verbosity is gone, --reallyquiet and --debug are
deprecated, and there's a new --verbose / -v
You rock!
Cheers,
Derek
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
On Mon, Jul 19, 2010 at 8:47 AM, Ethan Blanton e...@psg.com wrote:
Well, I, for one, would like to clarify that I didn't intend my
comments to be wholly negative; I think maybe you grokked that from
the first time, but let me say it anyway. ;-) I *like* the editable
Good to hear!
Starting a series of replies...
On Sat, Jul 17, 2010 at 1:40 AM, CooSoft Support
supp...@coosoft.plus.comwrote:
I'm not currently using 0.48 and from what I hear nor will I. I to want
comments to go in unmolested and not have white space stripped out. For me
that is a must.
I've found that
On Sat, Jul 17, 2010 at 3:03 PM, Aaron W. Hsu arcf...@sacrideo.us wrote:
Hey Everyone,
With all the negative responses regarding the new changelog editor, I
just thought I would weigh in with something a little more positive. I
actually do like the changes, on a whole, and think that we
On Sat, Jul 17, 2010 at 5:05 PM, Thomas Keller m...@thomaskeller.biz wrote:
So we _could_ extend the commit editor to do this, by providing fields
that are the file args (allowing Unix shell wildcards would be best) and
the --exclude arg.
If somebody would work on that, I'd rather let the
On Sun, Jul 18, 2010 at 12:11 AM, J Decker d3c...@gmail.com wrote:
Personally I always do my commits with ... -m my message ... so
I doubt this even affects me in the least.
Correct. If you use -m, or edit the _MTN/log file or use --message-file you
shouldn't be affected by the new
On Tue, Jul 13, 2010 at 9:22 PM, Tero Koskinen tero.koski...@iki.fi wrote:
I also dislike the new commit message format. While I can
jump down 14 lines, I think the jump is an usability issue
and the behaviour should be reverted back to previous version.
Many editors (emacs, vi, nano at
On Mon, Jun 14, 2010 at 12:02 PM, Jack Lloyd ll...@randombit.net wrote:
I think this is new in 0.48:
$ mtn ci readme.txt doc/log.txt configure.py -m Tick to 1.9.9-dev
mtn: warning: including missing parent ''
mtn: warning: including missing parent 'doc'
[...]
Kind of obnoxious; I can
I made a slight change to the date parsing code
in ff193643616656b62a465d043676e3faf83418b7 to re-add the check for stray
characters following the date that aren't matched by the specified format. I
also added a simple check for this condition to the associated unit tests to
make it clear what the
On Thu, Jun 3, 2010 at 5:45 PM, Thomas Keller m...@thomaskeller.biz wrote:
I've just talked with Thomas Moschny on IRC and I listened again to his
and other people's concerns about switching too fast to 1.0. I think the
concerns are reasonable, so we've discussed this issue and concluded the
On Thu, Jun 3, 2010 at 5:03 AM, Thomas Keller m...@thomaskeller.biz wrote:
206 diffing_a_file_within_revision_outside_a_workspaceFAIL (line 52)
301 logging_a_file_within_revision_outside_a_workspaceFAIL (line 22)
Both tests fail with restriction includes unknown path on foo2 / foo1.
This
On Sun, May 30, 2010 at 5:01 PM, Thomas Keller m...@thomaskeller.biz wrote:
4) For me on Mac OS X all tests run through, even one unexpectedly
(log_--diff) - Derek, should this test be un-xfailed?
Indeed it should. I'll clean that up tonight.
Cheers,
Derek
Update of bug #17499 (project monotone):
Open/Closed: In Test = Closed
___
Reply to this item at:
http://savannah.nongnu.org/bugs/?17499
___
Update of bug #20447 (project monotone):
Open/Closed: In Test = Closed
mtn version --full: C:\dev\fortamtn --full-version
monotone 0.35 (base revision: f92dd754bf5c1e6eddc9c462b8d68691cfeb7f8b)
Update of bug #22044 (project monotone):
Open/Closed: In Test = Closed
___
Reply to this item at:
http://savannah.nongnu.org/bugs/?22044
___
On Thu, May 27, 2010 at 9:54 AM, Derek Scherger de...@echologic.com wrote:
As I've announced earlier I'd like to start the machinery for the next
monotone release now that the database management branch has landed. So
if you have anything you'd also really like to see in the next monotone
On Fri, May 28, 2010 at 1:30 AM, Thomas Keller m...@thomaskeller.biz wrote:
I agree that continueing the current versioning scheme, just with a
prefixed 1., won't make much sense any longer, but I'm against
complicating this too much. A new easy rule for now could be:
1) if a release only
On Thu, May 27, 2010 at 1:38 AM, Thomas Keller m...@thomaskeller.biz wrote:
Hi all!
As I've announced earlier I'd like to start the machinery for the next
monotone release now that the database management branch has landed. So
if you have anything you'd also really like to see in the next
On Wed, May 26, 2010 at 11:20 AM, Thomas Keller m...@thomaskeller.biz wrote:
Whatever we come up with here, its a bit out of the scope of this branch
- lets get this merged at first and make the other change later :)
Agreed, based on your following comment. ;)
And it just came into my
On Thu, May 20, 2010 at 5:04 AM, Stephen Leake
stephen_le...@stephe-leake.org wrote:
It's currently dying with some mysterious C messages:
These do _not_ look easy to fix.
So I'm looking at where strptime is used, to see what the impact of this
is.
It's used in three places:
On Wed, May 19, 2010 at 3:56 AM, Stephen Leake
stephen_le...@stephe-leake.org wrote:
Various web links hint that strptime is in glibc, so I don't understand
why it's not in MinGW.
FWIW man strptime here says:
SYNOPSIS
#define _XOPEN_SOURCE /* glibc2 needs this */
#include
On Tue, May 18, 2010 at 2:49 AM, Stephen Leake
stephen_le...@stephe-leake.org wrote:
which identifies 'strptime' as an XSI; X/Open System Interfaces
Extension. So apparently MinGW doesn't support that.
Annotate says 'strptime' was added recently, as part of the
changelog-editor work:
Uh
On Tue, May 18, 2010 at 3:40 PM, Thomas Keller m...@thomaskeller.biz wrote:
Ok here we go - code looks very good overall, some minor questions:
1)
+case restricted_path::required:
+case restricted_path::excluded_required:
+ if (path_depth == 0)
+
On Mon, May 17, 2010 at 2:26 AM, Thomas Keller m...@thomaskeller.biz wrote:
Ok, as long as you have documented that for the revert command,
everything should be fine. A short note in NEWS shouldn't hurt as well.
Done and ready to merge. Any objections?
Cheers,
Derek
On Mon, May 17, 2010 at 2:33 AM, Thomas Keller m...@thomaskeller.biz wrote:
\2) I'd like to get my nvm.experiment.database-management branch ready
and merged in as well, so the change I did earlier to mtn setup (which
now creates a database if none is given) is changed to create a
database in
Update of bug #15994 (project monotone):
Assigned to:None = dscherger
___
Reply to this item at:
http://savannah.nongnu.org/bugs/?15994
___
Update of bug #17499 (project monotone):
Assigned to:None = dscherger
___
Reply to this item at:
http://savannah.nongnu.org/bugs/?17499
___
Update of bug #22044 (project monotone):
Status:None = Duplicate
Assigned to:None = dscherger
___
Reply to this item at:
On Sat, May 15, 2010 at 11:41 AM, Derek Scherger de...@echologic.comwrote:
I've started a new branch net.venge.monotone.restrictions.implicit-includes
that changes the restrictions code to always include the parents of
explicitly included nodes.
This turned out to be a relatively simple
On Sun, May 16, 2010 at 3:51 PM, Thomas Keller m...@thomaskeller.biz wrote:
Am 16.05.10 11:19, schrieb Stephen Leake:
Thomas Keller m...@thomaskeller.biz writes:
For the others: If you think your branch is ready for the final merge,
give me a note if you want to get it reviewed another
Update of bug #22044 (project monotone):
Open/Closed:Open = In Test
___
Reply to this item at:
http://savannah.nongnu.org/bugs/?22044
___
Update of bug #15994 (project monotone):
Status:None = Fixed
___
Reply to this item at:
http://savannah.nongnu.org/bugs/?15994
___
Update of bug #20447 (project monotone):
Status:None = Fixed
Open/Closed:Open = In Test
mtn version --full: C:\dev\fortamtn --full-version
Update of bug #15994 (project monotone):
Open/Closed:Open = In Test
___
Reply to this item at:
http://savannah.nongnu.org/bugs/?15994
___
Update of bug #17499 (project monotone):
Status:None = Fixed
Open/Closed:Open = In Test
___
Reply to this item at:
Update of bug #12773 (project monotone):
Open/Closed: In Test = Closed
___
Reply to this item at:
http://savannah.nongnu.org/bugs/?12773
___
I've merged the changelog-editor branch back to mainline.
If you're running from current builds you'll now see much more detail in
your editor when committing and it will look very similar to the output of
status and log.
Cheers,
Derek
(fingers crossed)
I've started a new branch net.venge.monotone.restrictions.implicit-includes
that changes the restrictions code to always include the parents of
explicitly included nodes.
This turned out to be a relatively simple change and I've updated the
restriction unit-tests so that they are all passing.
On Mon, May 10, 2010 at 3:53 PM, Thomas Keller m...@thomaskeller.bizwrote:
* #20447: mtn diff filename fails inside of a renamed directory
- net.venge.monotone.bugfest-2010.20447-dscherger
- @Derek: whats your plan here? Is this reviewable?
Patch looks ok, if you add tests for the
2010/5/12 Stephen Leake stephen_le...@stephe-leake.org
Zbigniew Zagórski invalid.nore...@gnu.org writes:
Follow-up Comment #2, bug #29835 (project monotone):
(slept with that problem and ... )
1. forget current patch, it's broken in regards to error/empty branches
handling. I am
On Mon, May 10, 2010 at 6:24 AM, Stephen Leake
stephen_le...@stephe-leake.org wrote:
It is a minor modification of revert; I factored out the common code.
undrop just tells revert not to revert a file that is present in the
workspace, because it had changes when it was dropped.
Ahh I see.
On Mon, May 10, 2010 at 6:21 AM, Stephen Leake
stephen_le...@stephe-leake.org wrote:
Thomas Keller m...@thomaskeller.biz writes:
Here is a little analysis of the recent bugfest efforts.
Thanks for all your work in organizing this.
I'll second that, you've done a great job of keeping
On Mon, May 10, 2010 at 3:47 PM, Stephen Leake
stephen_le...@stephe-leake.org wrote:
I don't know; --no-content to me sounds like don't revert content,
just renmaes and other stuff. That's not the same as 'undrop', which
does revert content if the file actually got deleted from the workspace.
On Mon, May 10, 2010 at 5:53 AM, Stephen Leake
stephen_le...@stephe-leake.org wrote:
drop --recursive dir1
(realize mistake)
undrop dir1/file1
What would that do?
Currently, this gives an error:
mtn: warning: restriction excludes addition of 'dir1' but includes
addition of
On Mon, May 10, 2010 at 3:20 PM, Thomas Keller m...@thomaskeller.biz wrote:
I think what he meant is the following:
$ mtn mv a b
$ edit b
$ mtn revert b
$ edit / save b again
You end up with an unknown file b because of course your editor doesn't
get the info that the rename was
On Mon, May 10, 2010 at 3:10 PM, Thomas Keller m...@thomaskeller.biz wrote:
$ mtn add a # non-recursive
$ mtn add a/... # recusive
$ mtn revert a # non-recursive
$ mtn revert a/... # recursive
I'm not sure how we'd represent a recursive revert of the entire
workspace,
maybe 'mtn
On Mon, May 10, 2010 at 3:53 PM, Thomas Keller m...@thomaskeller.biz wrote:
* #20447: mtn diff filename fails inside of a renamed directory
- net.venge.monotone.bugfest-2010.20447-dscherger
- @Derek: whats your plan here? Is this reviewable?
Patch looks ok, if you add tests for the
On Sun, May 9, 2010 at 5:28 PM, Thomas Keller m...@thomaskeller.biz wrote:
* #20447: mtn diff filename fails inside of a renamed directory
- net.venge.monotone.bugfest-2010.20447-dscherger
- @Derek: whats your plan here? Is this reviewable?
I spent most of the day working on this and made
On Sun, May 9, 2010 at 8:24 AM, Stephen Leake invalid.nore...@gnu.orgwrote:
And, in general, support for option overwriting via --[no-]*, so you can
put
--update-workspace in the defaults, and override it on occasion.
Agreed. Ideally such a system would allow for --foo --no-foo --foo etc. so
So I spent quite a few hours on Saturday working on
https://savannah.nongnu.org/bugs/?20447 which turned out to be somewhat more
involved that I was expecting.
The basic problem is this: given a file f in a directory d
$ mtn mv d d2
$ edit f
$ mtn status
# rename d to d2
# patch d2/f from
mtn add is non-recursive by default but allows for --recursive if you want
it.
mtn revert is recursive by default and doesn't allow for an obvious way of
being non-recursive (I believe --depth=N will stop the recursion at the
specified depth).
So, which is more dangerous (1) accidentally adding
Update of bug #12773 (project monotone):
Assigned to:None = dscherger
___
Reply to this item at:
http://savannah.nongnu.org/bugs/?12773
___
Update of bug #12773 (project monotone):
Open/Closed:Open = In Test
___
Reply to this item at:
http://savannah.nongnu.org/bugs/?12773
___
Update of bug #12773 (project monotone):
Status:None = Fixed
___
Reply to this item at:
http://savannah.nongnu.org/bugs/?12773
___
Update of bug #27929 (project monotone):
Status:None = Wont Fix
Open/Closed:Open = Closed
___
Reply to this item at:
Update of bug #20447 (project monotone):
Assigned to:None = dscherger
mtn version --full: C:\dev\fortamtn --full-version
monotone 0.35 (base revision: f92dd754bf5c1e6eddc9c462b8d68691cfeb7f8b)
Follow-up Comment #2, bug #22417 (project monotone):
Monotone currently also fails for missing files which are somewhat similar to
unreadable files. Perhaps we should still fail but with a nicer message rather
than a hard crash.
___
On Thu, May 6, 2010 at 11:48 AM, Thomas Keller m...@thomaskeller.biz wrote:
Am 06.05.10 13:09, schrieb Stephen Leake:
2) Create a new branch nvm.bugfest-2010.savane-bug-id-savane-login
and work on the fix.
There are several failing tests on main, so I suggest we branch from
On Tue, Apr 20, 2010 at 3:57 PM, Thomas Keller m...@thomaskeller.biz wrote:
In the meantime what I would really really want to get rid of are
boolean function arguments - so maybe you could start and make the code
a little easier to read by passing a more describable enum value...?
Agreed.
On Thu, Apr 29, 2010 at 5:00 AM, Thomas Keller m...@thomaskeller.biz wrote:
Ok, two people now - what about the others?
I'm in if the timing works.
Cheers,
Derek
Yes I still need to get to that email about the changelog editor too ;)
___
On Wed, Apr 28, 2010 at 5:14 AM, Thomas Moschny thomas.mosc...@gmx.dewrote:
mtn ls branches | grep -v -E '^(\w+(-\w+)*)(\.\w+(-\w+)*)*$'
shows only one branch that doesn't match in my local copy of the
monotone db (prjek.net:tester).
And what would you do with that branch if this
On Wed, Apr 28, 2010 at 1:34 AM, Thomas Keller m...@thomaskeller.biz wrote:
+1/2 - this is similar to my last proposal (with : as separators, but
I'd accept , as well) - but the mandatory ? still strikes me. Do you
see any way to avoid ? for the 90% use case (sync a single branch
without
On Tue, Apr 27, 2010 at 5:54 PM, Zack Weinberg za...@panix.com wrote:
On Tue, Apr 27, 2010 at 4:42 PM, Timothy Brownawell tbrow...@prjek.net
wrote:
Is the occasional backslash really that bad? '%' conflicts with
urlencoding
(and '*' would only actually glob things if you have some really
On Sat, Apr 17, 2010 at 4:53 PM, Derek Scherger de...@echologic.com wrote:
How about something simple:just before writing out a new _MTN/options read
in the current one and see if there is any difference between what is about
to be written and what is already written, then only write out new
On Sun, Apr 18, 2010 at 2:40 PM, Thomas Keller m...@thomaskeller.biz wrote:
Heh, very cool, thanks Derek! Does this code change also fix the problem
that _MTN/options is written out even if the command does not succeed?
I don't think so. This change was to the set_options function in
2010/4/15 Derek Scherger de...@echologic.com
2010/4/14 Stéphane Gimenez d...@gim.name
First remark: mtn status ask for my password and it's rather
inconvenient (I'm not using ssh agent). Same for mtn commit just after
it's invocation and prior to the real commit.
Hrm.. I hadn't noticed
On Sat, Apr 17, 2010 at 6:34 AM, Thomas Keller m...@thomaskeller.biz wrote:
This is only partially a problem of the hook. The options system simply
has no general code to accept --no-something options which would
switch the default of the --something value to the opposite.
Allowing a
On Sat, Apr 17, 2010 at 1:27 AM, Thomas Keller invalid.nore...@gnu.orgwrote:
1) Save any given options back to _MTN/options at the very end of the
execution (f.e. in monotone.cc) _after_ it has been clear that no exception
occurred - so we don't remember possibly harmful settings.
2) Only
2010/4/14 Stéphane Gimenez d...@gim.name
Hi,
I've been following your discussion, and I tried the nice features in
this changlog editor branch.
First remark: mtn status ask for my password and it's rather
inconvenient (I'm not using ssh agent). Same for mtn commit just after
it's
On Tue, Apr 13, 2010 at 1:29 AM, Stephen Leake
stephen_le...@stephe-leake.org wrote:
Derek Scherger de...@echologic.com writes:
Presumably someone could write a monotone-commit-mode for emacs and
something similar for vim that would allow the editor to prevent you from
editing things
On Mon, Apr 12, 2010 at 4:06 PM, Thomas Keller m...@thomaskeller.biz wrote:
No, I just tried it out and it already looks much nicer, though I still
miss the end of the editable changelog area somewhat - maybe this is
just me who looks for some visual separator.
One minor peeve I have with
On Sun, Apr 11, 2010 at 12:38 PM, Thomas Keller m...@thomaskeller.biz wrote:
If there is text in _MTN/log then it is displayed in the changelog
section.
Ah, didn't thought of this - nice!
We could choose to omit this section unless there is something in
_MTN/log.
Yes, I'd say so.
Hi folks, I think the experimental changelog editor branch that I've been
working on recently is to the point where we can consider merging it to
mainline. (see the net.venge.monotone.experiment.changelog-editor branch)
The original motivation for this branch was to help deal with the problem of
On Sat, Apr 10, 2010 at 1:28 PM, Thomas Keller m...@thomaskeller.biz wrote:
While I appreciate this unification, I think the ChangeLog: display in
mtn status is bogus and should be removed, no?
If there is text in _MTN/log then it is displayed in the changelog section.
We could choose to omit
On Tue, Feb 23, 2010 at 1:48 AM, Stephen Leake
stephen_le...@stephe-leake.org wrote:
hend...@topoi.pooq.com writes:
Right; you can pull any branch into any repository (= monotone
database). But then you do have to be careful not to accidentally send
a branch to an upstream repository; we
On Wed, Feb 3, 2010 at 5:30 PM, Stephen Leake
stephen_le...@stephe-leake.org wrote:
Thomas Keller m...@thomaskeller.biz writes:
I'm not sure why the SQL update on next_roster_node_number should fail -
given the fact that a previous INSERT worked - Stephe, Lapo, could you
please have a
http://savannah.nongnu.org/bugs/?28372
Apparently author names that don't match the Name email format are
imported ok by git but the resulting repo has some sort of problems,
although I don't have any details on the nature of the problems.
Currently we grab both the value of the author cert and
On Fri, Dec 18, 2009 at 2:50 AM, Felipe Contreras
felipe.contre...@gmail.com wrote:
Anything wrong with this patch? Derek, can you please apply it?
Looks fine to me. Applied in 01e79cd4d9e0e307431d16422820a7537b23df92. Sorry
it took so long.
Cheers,
Derek
On Fri, Dec 18, 2009 at 2:31 AM, Thomas Keller m...@thomaskeller.biz wrote:
Ok, I'm looking forward to your merge to nvm then.
Merged in a8ac6a5f9fdd9d124cdd42d965e66897e030ecc8.
Cheers,
Derek
___
Monotone-devel mailing list
On Tue, Dec 15, 2009 at 1:18 PM, Thomas Keller m...@thomaskeller.biz wrote:
Am 01.12.09 06:49, schrieb Derek Scherger:
On Tue, Nov 24, 2009 at 12:59 AM, Thomas Keller m...@thomaskeller.biz
mailto:m...@thomaskeller.biz wrote:
At first sorry for answering this late. Too much attention
On Wed, Dec 16, 2009 at 9:35 AM, Phil Hannent p...@hannent.co.uk wrote:
Does the git crash log contain anything helpful?
Not that I can tell, attached.
Yeah, it looks almost completely empty. I suspect it's crashing on the first
blob.
I assume you must be running through a pipe and it
On Mon, Dec 14, 2009 at 9:34 AM, Phil Hannent p...@hannent.co.uk wrote:
Hello,
I am running a git_export command with monotone 0.45 on Windows XP in a
cygwin shell, however it fails with:
mtn: loading
mtn: 2558/2558
fatal: Unsupported command: blob
fast-import: dumping crash report to
On Tue, Nov 24, 2009 at 12:59 AM, Thomas Keller m...@thomaskeller.biz wrote:
Am 24.11.2009 06:57, schrieb Derek Scherger:
On Fri, Nov 20, 2009 at 4:01 PM, Thomas Keller m...@thomaskeller.biz
wrote:
1) If an update to a revision failed, f.e. because the addition /
removal of a node
On Fri, Nov 20, 2009 at 4:01 PM, Thomas Keller m...@thomaskeller.biz wrote:
1) If an update to a revision failed, f.e. because the addition /
removal of a node is blocked because of unversioned files, it tells me
to re-run the process with --move-conflicting-paths - however what
should be
I've finally found the time to finish up the bisect command I started
working on earlier in the year and it's now ready for review on the
net.venge.monotone.bisect branch.
There's one item I'd like some feedback on before merging this to mainline
though: In the process of bisecting, the various
On Wed, Sep 9, 2009 at 12:29 AM, Richard Levitte rich...@levitte.orgwrote:
Hmmm, you're writing something about unchecked pulls, and it has me
wonder if that could be an idea to explore...
Right now, with just half a minute of thought, I wonder if it would be
possible to have some kind of
On Wed, Aug 26, 2009 at 7:44 AM, hend...@topoi.pooq.com wrote:
But if protocol negotiation won't do the whole job (and it looks as
if it may not) it would simplify my life immensely if the protocol to
use were made a command-line parameter on the mtn sync command. We
could even store a
On Mon, Aug 24, 2009 at 5:39 PM, Timothy Brownawell tbrow...@prjek.netwrote:
On Mon, 2009-08-24 at 19:23 -0400, hend...@topoi.pooq.com wrote:
Wasn't there a list of things that also needed a flag day -- with
the intent that we do them all together and thus need only one flag day?
All I'm
On Sat, Aug 22, 2009 at 11:20 PM, Zack Weinberg za...@panix.com wrote:
It doesn't need Boost.System, but it does still depend on a few pieces
of boost that we're not currently using, notably
boost::date_time::posix_time, bleah.
True enough. This looks like it's mostly internal to asio,
On Sat, Aug 22, 2009 at 11:49 AM, Timothy Brownawell tbrow...@prjek.netwrote:
I think dscherger is looking into using boost::asio
(net.venge.monotone.asio), which includes ssl support (I think including
client certificates, which we need) but would take us back to linking
against boost
On Sat, Aug 22, 2009 at 12:40 PM, Stephen Leake
stephen_le...@stephe-leake.org wrote:
Building that branch on Debian dies in netsync.cc on:
#include netxx/address.h
#include netxx/peer.h
#include netxx/probe.h
#include netxx/socket.h
#include netxx/sockopt.h
#include netxx/stream.h
On Sat, Aug 22, 2009 at 1:59 PM, Timothy Brownawell tbrow...@prjek.netwrote:
The two that come to mind are
* different (and therefore annoying) build system
100% agree, however with plain asio we don't need to pull in boost and its
sucky build system so this shouldn't be an issue.
*
On Sat, Aug 22, 2009 at 3:45 PM, Zack Weinberg za...@panix.com wrote:
I suppose I should pop back in at this point, since I started the asio
branch, and admit that I got stuck. In addition to the above
problems, asio has what is IMO a serious design flaw: its I/O channel
objects are
On Sat, Aug 22, 2009 at 11:15 PM, Zack Weinberg za...@panix.com wrote:
I wasn't aware that SSL was on the table, to be honest :) Libevent
Yeah, what got me thinking about asio was thinking about nuskool and
wondering what we might do to support https, particularly on the client
side. We
On Mon, Jul 13, 2009 at 5:39 PM, Stephen Leake
stephen_le...@stephe-leake.org wrote:
I'd like to add a '--reverse' option to diff.
...
if (app.opts.reverse)
{
// FIXME: this breaks something in graph.cc
make_cset(new_roster, restricted_roster, excluded);
1 - 100 of 345 matches
Mail list logo
