[Monotone-devel] distributed wiki?

[Hendrik Boom]

Wikis usually use a revision-control system to store their repositories.
Are there any known wikis that use a distributed revision-control system?
If not, would it be worthwhile investigating basing one on monotone?

And ... what kind of user interface, comprehensible by the rank novice,
would explain to him what's going on when there are multiple heads in a
page?

-- hendrik





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

[Monotone-devel] Re: distributed wiki?

[Hendrik Boom]

On Thu, 08 Feb 2007 21:35:00 -0600, Matthew A. Nicholson wrote:

> Justin Patrin wrote:
>> On 2/8/07, Hendrik Boom <[EMAIL PROTECTED]> wrote:
>>> Wikis usually use a revision-control system to store their
>>> repositories. Are there any known wikis that use a distributed
>>> revision-control system? If not, would it be worthwhile investigating
>>> basing one on monotone?
>>>
>>> And ... what kind of user interface, comprehensible by the rank novice,
>>> would explain to him what's going on when there are multiple heads in a
>>> page?
>>>
>>>
>> Someone mentioned ikiwiki on the list a while ago and it was mentioned
>> again during the summit. Someone was working on support for it but noone
>> seems to know what came of that. In any case, ikiwiki seems like the way
>> to got for such a thing.
>> 

Right.  Found it in a thread startine 2006 oct 8.  Has there been any
progress on this front?

>> 
> My only problem with ikiwiki is that it is written in perl.  I wrote a
> wiki parser for my website in C++ using boost::spirit and it supports most
> of moin moin's syntax.

My two immediate thoughts on thos were:

(1) Oh good.  SOmeone's started the ball rolling.
(2) Too bad.  I'd wanted to try out a new programming language on a real
problem like this.

Seriously -- has anyone heard of progress on this front?

-- hendrik




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

[Monotone-devel] Re: distributed wiki?

[Hendrik Boom]

On Thu, 08 Feb 2007 21:35:00 -0600, Matthew A. Nicholson wrote:

> Justin Patrin wrote:
>> On 2/8/07, Hendrik Boom <[EMAIL PROTECTED]> wrote:
>>> Wikis usually use a revision-control system to store their
>>> repositories. Are there any known wikis that use a distributed
>>> revision-control system? If not, would it be worthwhile investigating
>>> basing one on monotone?
>>>
>>> And ... what kind of user interface, comprehensible by the rank novice,
>>> would explain to him what's going on when there are multiple heads in a
>>> page?
>>>
>>>
>> Someone mentioned ikiwiki on the list a while ago and it was mentioned
>> again during the summit. Someone was working on support for it but noone
>> seems to know what came of that. In any case, ikiwiki seems like the way
>> to got for such a thing.
>> 
>> 
> My only problem with ikiwiki is that it is written in perl.  I wrote a
> wiki parser for my website in C++ using boost::spirit and it supports most
> of moin moin's syntax.

Just found ikiwiki entry on the Debian packages site:
http://packages.debian.org/unstable/web/ikiwiki
It seems to indicate that ikiwiki is now happy working with mercurial.  So
it seems there is now a distributed wiki in existence.  Does anyone know
whether they have dealt with the UI problems involved in multiheading? 
You know, the ones discussed last October on this list?

-- hendrik






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

[Monotone-devel] Re: planning for resurrection

[Hendrik Boom]

On Wed, 02 Jul 2008 09:54:00 -0400, hendrik wrote:

> In another thread, I recently said,
> 
>> Now there are some large files that were build as part of normal
>> development, but were abandoned because of sustem limitations long ago.
>>  While I don't expect to develop in these directions myself, others
>> might well want to.
> 
>> If I check them in, and then delete them, they will be part of the
>> historical record, but it will be impossible to resurrect them later,
>> because of die die die merge.  So this is perhaps not the way to go.
> 
>> But if I don't delete them they will remain in the head of the active
>> project whether they are used or not.  This is also undesirable.
> 
>> Is there some clever way around this?  Would branches help?
> 
> Reading some more in the mailing list, I find that resurrection is a
> sore point.  But since it's unlikely that anyone will be doing anything
> with the abandoned files until someone decides to resurrect them, it
> would seem to suffice to check in a new file sometime in the future that
> happens to be the same as the old file.  There won't be revisions from
> the graves coming back to haunt us later -- just revisions on the
> resurrected file.
> 
> So I can, for now, just check the ancient relics in and delete them.
> 
> Does anyone see problems with this approach?  Or is there a better one?
> 
> -- hendrik

I guess there's the technique of checking the abandonware into a 
different branch, and just leaving it there.  Some of it could be other 
versions of  main-branch files, but they have diverged so much that they 
are effectively unmergeable at this point.

Would this work?  Or does it have unforeseen side effects?

-- hendrik



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

[Monotone-devel] Re: Blank spaces in monotone manual?

[Hendrik Boom]

The HTML version has the proper diagrams.  That may be a clue.  But the 
pdf would be better for printing and reading in bed, if it were correct.

-- hendrik



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

[Monotone-devel] Re: Text under revision control

[Hendrik Boom]

On Mon, 02 Mar 2009 13:43:40 -0500, Ethan Blanton wrote:

> hend...@topoi.pooq.com spake unto us the following wisdom:
>> Now the VCS could use a different difference algorithm when processing
>> them.  Or it could unpack them into something easier to process (like a
>> sequence of words instead of lines).  Or the word-processor could use a
>> better file-format, or be careful to preserve the locations of the
>> meaningless line numbers in the file, or insert many of them in
>> standard places (such as sentence breaks, or punctuation, or between
>> every two words).
> 
> Note that gnu wdiff works reasonably well with several plain-text
> formats, notably latex.  I use wdiff + latex + VCS quite often, with
> reasonably satisfactory results.  There is no 'wpatch', so wdiff is
> useful mainly for review, but that's OK -- one generally doesn't care
> how the VCS actually *stores* the diffs.
> 
> I've not integrated wdiff with monotone's external diff hooks, but I
> don't see why it couldn't be done.

I've considered these matters, and it raises a few questions.

(1) With monotone as it is now, would there be incompatibilities if I 
were to use a wdiff merge hook, and I sync with other data bases that do 
not?

(2) The simplest such hook would seem to be a procedure that breaks the 
input file into s sequence of one-word lines (more or less) then calls 
monotone's default merge to process those, and then converts the result 
back.  Is a default-merge callback available to the lua?

(3) Is there a technical reason why the default merge views files as 
sequences of lines to be inserted, removes, or kept instead of some other 
view, such as a sequence of bytes to be inserted, removed, or kept?  The 
latter would seem to be able to reduce the number of merge conflicts we 
encounter, and increase the number of file formats we play nice with.

-- hendrik



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

Re: [Monotone-devel] private key needed for sync?

[Hendrik Boom]

Brian Campbell wrote:
> You need to have a key in the server so the client can make
> sure it's connecting to the right server. Otherwise, someone
> could set up a bogus server so when you sync to it, all of
> your private code is sent to the malicious server.

How do you generate such a default signing key?
The tutorial/manual says something like
  monotone --db=~/database.db genkey [EMAIL PROTECTED]

But this generates a key for a specific person, somebody.
How does one generate the default signing key for the server itself?

-- hendrik


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

Re: [Monotone-devel] private key needed for sync?

[Hendrik Boom]

On Mon, Jun 27, 2005 at 03:19:49PM -0700, Nathaniel Smith wrote:
> On Mon, Jun 27, 2005 at 04:53:20PM -0400, Hendrik Boom wrote:
> > Brian Campbell wrote:
> > > You need to have a key in the server so the client can make
> > > sure it's connecting to the right server. Otherwise, someone
> > > could set up a bogus server so when you sync to it, all of
> > > your private code is sent to the malicious server.
> > 
> > How do you generate such a default signing key?
> > The tutorial/manual says something like
> >   monotone --db=~/database.db genkey [EMAIL PROTECTED]
> > 
> > But this generates a key for a specific person, somebody.
> > How does one generate the default signing key for the server itself?
> 
> You just pick something.  The off.net server uses "[EMAIL PROTECTED]";
> you can use whatever you like.  An email address that will get to the
> server administrator might be good ("[EMAIL PROTECTED]"?).
> Key names are just arbitrary strings (with some overly draconian rules
> about what characters are allowed -- should fix this at some point),
> and the use of email addresses is just a convention.

So if I generate any key in a database, that key becomes the default?
And adding a key with
 monotone ... read <...
doesn't make a default key?

-- hendrik


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

Re: [Monotone-devel] private key needed for sync?

[Hendrik Boom]

On Mon, Jun 27, 2005 at 06:55:22PM -0500, Timothy Brownawell wrote:
> On Mon, 2005-06-27 at 18:37 -0400, Hendrik Boom wrote:
> [snip]
> > So if I generate any key in a database, that key becomes the default?
> > And adding a key with
> >  monotone ... read <...
> > doesn't make a default key?
> 
> No, it guesses the default whenever it only has one private key to
> choose from. Doesn't matter whether it got that key from generating it
> or from reading it.
> 
> Tim

Not what I remember happening ... but I may misremember.  I think it
had read my personal key when it was still refusing to talk to me.
But when I had it generate a key, it worked OK.

-- hendrik

Thanks.  I have it working now, anyway.  I'll ask my next question
in a new thread.




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

[Monotone-devel] multiple collections

[Hendrik Boom]

What if I need to serve several collections, whose names have nothing in common?

Can I run something like

monotone -db=... serve my.site.com com.site.my.applesauce org.other.collection

?
Or is there a better method?

-- hendrik


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

[Monotone-devel] sqlite exec error column id is not unique

[Hendrik Boom]

It told me to send this to you.  The monotone I am using is the one
distributed with sarge.

-- hendrik

I deleted my server data base, recreated it, started the server,
set up the keys again, logged in as hendrik, and tried to sync.

[EMAIL PROTECTED]:~/dv/sandbox$ monotone 
--db=/home/hendrik/monotone/database.db sync topoi.pooq.com com.pooq
monotone: connecting to topoi.pooq.com
monotone: rebuilding merkle trees for collection com.pooq
monotone: including branch com.pooq.topoi.sandbox
monotone: [certs: 4] [keys: 1]
monotone: warning: first time connecting to server topoi.pooq.com; authenticity 
can't be established
monotone: warning: their key is 427ccc83f801158da61ac7a9cccda470f8a0b840
monotone: warning: saving public key for [EMAIL PROTECTED] to database
monotone: [bytes in: 214] [bytes out: 0] [revs in: 0] [revs out: 0]
monotone: fatal: std::runtime_error: sqlite exec error column id is not unique
monotone: this is almost certainly a bug in monotone.
monotone: please send this error message, the output of 'monotone 
--full-version',
monotone: and a description of what you were doing to [EMAIL PROTECTED]: wrote 
debugging log to MT/debug
[EMAIL PROTECTED]:~/dv/sandbox$
[EMAIL PROTECTED]:~/dv/sandbox$
[EMAIL PROTECTED]:~/dv/sandbox$
[EMAIL PROTECTED]:~/dv/sandbox$
[EMAIL PROTECTED]:~/dv/sandbox$ monotone --full-version
monotone 0.18 (base revision: e8c9e4eb0534a4c6e538935576330de34ec42052)
Running on: Linux 2.6.7-1-386 #1 Thu Jul 8 05:08:04 EDT 2004 i686
Changes since base revision:

new_manifest [cbc23fa42b07e4f6f7d3a327c5eb1d4f4a782a75]

old_revision [e8c9e4eb0534a4c6e538935576330de34ec42052]
old_manifest [cbc23fa42b07e4f6f7d3a327c5eb1d4f4a782a75]


  Generated from data cached in the distribution;
  further changes may have been made.

  Generated from data cached in the distribution;
  further changes may have been made.

  Generated from data cached in the distribution;
  further changes may have been made.
[EMAIL PROTECTED]:~/dv/sandbox$


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

Re: [Monotone-devel] sqlite exec error column id is not unique

[Hendrik Boom]

On Mon, Jul 04, 2005 at 12:36:43AM -0700, Nathaniel Smith wrote:
> On Sun, Jul 03, 2005 at 09:28:53PM -0400, Hendrik Boom wrote:
> > It told me to send this to you.  The monotone I am using is the one
> > distributed with sarge.
> 
> Can you send the file 'MT/debug' along too?
> 
> My first guess is that you have some keys on the server and in your
> local db with the same name but generated at different times, and
> we're giving a really horrid error message; but the debug log should
> clarify things.

The new server does have a different key from the old one, although
it has the same name.  The client did detect the change, and asked 
me to run the command to purge keys, which I did.  Of course I didn't think
anything was amiss at that point.  The problem I am reporting happened
after that, so I no longer have the older messages.

I hope I haven't messed up the MT/debig file by subsequent actions.
I'm puzzled by the date on eht first line on MT/debug -- both computers
have fairly well-synchonized, correct, clock.  Both of them know
it is 2005 now, and that July 8 hasn't happened yet.

-- hendrik

> 
> -- Nathaniel
> 
> -- 
> "If you can explain how you do something, then you're very very bad at it."
>   -- John Hopfield

There doesn't seem to be one for the server.
But here's MT/debug from the client:

started up on Linux 2.6.7-1-386 #1 Thu Jul 8 05:08:04 EDT 2004 i686
command line: 'monotone', '--db=/home/hendrik/monotone/database.db', 'sync', 
'topoi.pooq.com', 'com.pooq'
set locale: LC_CTYPE=en_CA.UTF-8, LC_MESSAGES=en_CA.UTF-8
initial path is /home2/hendrik/dv/sandbox
searching for 'MT' directory with root '/'
search for 'MT' ended at '/home2/hendrik/dv/sandbox' with '' removed
initializing from directory /home2/hendrik/dv/sandbox
found working copy directory /home2/hendrik/dv/sandbox
options path is MT/options
local dump path is MT/debug
setting dump path to MT/debug
skipping nonexistent rcfile '/home/hendrik/.monotonerc'
skipping nonexistent rcfile 'MT/monotonerc'
executing sync command
db.fetch("SELECT domain, name, value FROM db_vars")
db.fetch("SELECT domain, name, value FROM db_vars")
lua isfunction() failed in get_fn
db.fetch("SELECT id from 'private_keys'")
db.fetch("SELECT id, name, value, keypair, signature FROM 'revision_certs' 
WHERE name = 'branch'")
db.execute("BEGIN")
connecting to topoi.pooq.com
rebuilding merkle trees for collection com.pooq
db.fetch("SELECT id, name, value, keypair, signature FROM 'revision_certs' 
WHERE name = 'branch'")
including branch com.pooq.topoi.sandbox
db.fetch("SELECT branch, epoch FROM branch_epochs")
db.fetch("SELECT hash, id, keypair FROM 'revision_certs'")
db.fetch("SELECT id FROM public_keys WHERE id = '[EMAIL PROTECTED]'")
db.fetch("SELECT keydata FROM public_keys where id = '[EMAIL PROTECTED]'")
read 214 bytes from fd 4 (peer topoi.pooq.com)
processing 0 byte input buffer from peer topoi.pooq.com
server key has name [EMAIL PROTECTED], hash 
427ccc83f801158da61ac7a9cccda470f8a0b840
db.fetch("SELECT domain, name, value FROM db_vars")
warning: first time connecting to server topoi.pooq.com; authenticity can't be 
established
warning: their key is 427ccc83f801158da61ac7a9cccda470f8a0b840
db.execute("INSERT OR REPLACE INTO db_vars VALUES('known-servers', 
'dG9wb2kucG9vcS ...")
db.fetch("SELECT id FROM public_keys WHERE hash = 
'427ccc83f801158da61ac7a9cccda470f8a0b840'")
warning: saving public key for [EMAIL PROTECTED] to database
db.execute("INSERT INTO public_keys 
VALUES('427ccc83f801158da61ac7a9cccda470f8a0b8 ...")
db.execute("ROLLBACK")






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

Re: [Monotone-devel] sqlite exec error column id is not unique

[Hendrik Boom]

On Mon, Jul 04, 2005 at 05:54:21PM -0400, Hendrik Boom wrote:
> On Mon, Jul 04, 2005 at 12:36:43AM -0700, Nathaniel Smith wrote:
> > On Sun, Jul 03, 2005 at 09:28:53PM -0400, Hendrik Boom wrote:
> > > It told me to send this to you.  The monotone I am using is the one
> > > distributed with sarge.
> > 
> > Can you send the file 'MT/debug' along too?
> > 
> > My first guess is that you have some keys on the server and in your
> > local db with the same name but generated at different times, and
> > we're giving a really horrid error message; but the debug log should
> > clarify things.
> 
> The new server does have a different key from the old one, although
> it has the same name.  The client did detect the change, and asked 
> me to run the command to purge keys, which I did.  Of course I didn't think
> anything was amiss at that point.  The problem I am reporting happened
> after that, so I no longer have the older messages.
> 
> I hope I haven't messed up the MT/debig file by subsequent actions.
> I'm puzzled by the date on eht first line on MT/debug -- both computers
> have fairly well-synchonized, correct, clock.  Both of them know
> it is 2005 now, and that July 8 hasn't happened yet.

Should I wipe *all* my repositories and start over again?

-- hendrik


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

Re: [Monotone-devel] Keyword substitution?

[Hendrik Boom]

On Wed, Jul 27, 2005 at 06:22:33PM +0200, Richard Levitte - VMS Whacker wrote:
> In message <[EMAIL PROTECTED]> on Wed, 27 Jul 2005 08:58:42 -0700, "Todd A. 
> Jacobs" <[EMAIL PROTECTED]> said:
> 
> nospam> Sure there is: exported files. Not everything people keep in
> nospam> VCS is source code. Web pages, shell scripts, and man pages
> nospam> are some examples that come to mind where having some sort of
> nospam> version information embedded in the file itself would be very
> nospam> useful, and where an external "version file" would not be a
> nospam> reliable mechanism.
> 
> Hmm, OK, I do see your point.  Doesn't mean I like it, though...
> 
> And oh, repeat after me: "revision", not "version".

Perhaps a revision number could be inserted (if desired)
when a revision is checked in, thather than when it is exported?
That way the external version will be identical to the one in
the database?

Or maybe it could be inserted when the file is exported from
monotone to elsewhere, if desired.  And at the same time create
that revision -- with the externally known revision number -- into
the monotone data base, possibly marked as an exported version?

-- hendrik

> 
> Cheers,
> Richard
> 
> -
> Please consider sponsoring my work on free software.
> See http://www.free.lp.se/sponsoring.html for details.
> 
> -- 
> Richard Levitte [EMAIL PROTECTED]
> http://richard.levitte.org/
> 
> "When I became a man I put away childish things, including
>  the fear of childishness and the desire to be very grown up."
>   -- C.S. Lewis
> 
> 
> ___
> Monotone-devel mailing list
> Monotone-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/monotone-devel


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

Re: [Monotone-devel] Keyword substitution?

[Hendrik Boom]

On Wed, Jul 27, 2005 at 10:47:41PM +0200, Richard Levitte - VMS Whacker wrote:
> In message <[EMAIL PROTECTED]> on Wed, 27 Jul 2005 14:09:32 -0400, Hendrik 
> Boom <[EMAIL PROTECTED]> said:
> 
> hendrik> Perhaps a revision number could be inserted (if desired)
> hendrik> when a revision is checked in, thather than when it is
> hendrik> exported?  That way the external version will be identical to
> hendrik> the one in the database?
> 
> If done on checkin, it will generate all kinds of problems.  First of
> all, since the revision has a hash of the manifest, which has a hash
> of the file, changing the file will change the hash of the file, which
> will change the manifest, which will change the hash of the manifest,
> which will change the revision, which will change the revision hash
> (ID), so you need to change that in the file...  Now, let's all sing:
> o/~ Neverending sto-ory... o/~

I was thinking of revision numbers for external consumption --
you know, the ones that look like 5.7.-2a-sarge4.6 and such.
These would be chosen by the programmer or release manager,
not computed as a hash, not generated by monotone.
As such, there would be no need to compute a fixed-point
for a hash function.

> 
> hendrik> Or maybe it could be inserted when the file is exported from
> hendrik> monotone to elsewhere, if desired.  And at the same time
> hendrik> create that revision -- with the externally known revision
> hendrik> number -- into the monotone data base, possibly marked as an
> hendrik> exported version?
> 
> Well, substitution could happen on export, as long as the keywords are
> canonicalised back.  If that's to happen, I actually like the
> subversion way, where you have to say explicitely which keywords
> should be expanded.  If monotone is to have keywords, I suggest doing
> it that way (perhaps by creative use of .mt-attrs).

Yes.  I don't want the marker for an insertion into a C program
being recognised in my binary files either.

> 
> Either way, keyword expansion is an error-prone business which
> requires great thought and care, so let's not rush into it.  We have
> bigger issues to deal with, so I suggest we put the keyword thought on
> hold for now.

No need to rush forward with an implementation before the design is done!
But the time to design is now, when we have the time to do it right.
Maybe next year we'll know what we should do!

-- hendrik


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

Re: [Monotone-devel] Keyword substitution?

[Hendrik Boom]

On Sat, Jul 30, 2005 at 01:48:45AM +0200, Richard Levitte - VMS Whacker wrote:
> In message <[EMAIL PROTECTED]> on Fri, 29 Jul 2005 19:35:26 -0400, Hendrik 
> Boom <[EMAIL PROTECTED]> said:
> 
> hendrik> On Wed, Jul 27, 2005 at 10:47:41PM +0200, Richard Levitte - VMS 
> Whacker wrote:
> hendrik> > If done on checkin, it will generate all kinds of problems.
> hendrik> > First of all, since the revision has a hash of the
> hendrik> > manifest, which has a hash of the file, changing the file
> hendrik> > will change the hash of the file, which will change the
> hendrik> > manifest, which will change the hash of the manifest, which
> hendrik> > will change the revision, which will change the revision
> hendrik> > hash (ID), so you need to change that in the file...  Now,
> hendrik> > let's all sing:  o/~ Neverending sto-ory... o/~
> hendrik> 
> hendrik> I was thinking of revision numbers for external consumption --
> hendrik> you know, the ones that look like 5.7.-2a-sarge4.6 and such.
> hendrik> These would be chosen by the programmer or release manager,
> hendrik> not computed as a hash, not generated by monotone.
> hendrik> As such, there would be no need to compute a fixed-point
> hendrik> for a hash function.
> 
> Hmm, wait, are you thinking of some kind of specific cert that would
> be used for this, or tags, or what?

I suppose it could be.

-- hendrik


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

Re: [Monotone-devel] Re: Keyword substitution?

[Hendrik Boom]

On Wed, Aug 03, 2005 at 10:10:14AM +0100, Bruce Stephens wrote:
> "Todd A. Jacobs" <[EMAIL PROTECTED]> writes:
> 
> > On Tue, Aug 02, 2005 at 06:55:42PM +0100, Bruce Stephens wrote:
> 
> [...]
> 
> >>I suspect it's just as likely that you'd have some file (a script or
> >>bit of config or something) that came from some revision but had
> >>(possibly) been changed a little.  You'd want to know where it came
> >>from to know how it had been changed, and perhaps how it had been
> >>revised in the repository.  And in that case searching for its hash
> >>would likely be a waste of time, because it's probably been changed.
> >>Having a keyword of some kind might help, in that case.
> >
> > Yes, that's exactly it. :) And of course, in a widely-distributed
> > monotone group, some people may or may not be tracking various
> > branches so being able to tell which repository a particular file
> > came from would be helpful, too.
> 
> OK, that sounds like a use case: you want to be able to export a
> revision of files, and later (perhaps after they've been changed),
> discover where they came from.  
> 
> (You aren't alone.  At work we have occasion to do that kind of thing.
> Most of our code is binary, but there's a fair amount of scripting,
> and occasionally we've suggested customers patch the scripts and maybe
> just "oh, try this one" from a later version.  I don't think we've
> ever lost track to the extent that we need to look at the CVS
> keywords, but I can imagine it happening.)

One hack might be to take the ecternally modified file, diff it
arainst all the revisions in the database, and see which ones
differ the least.

Then use judgement.

-- hendrik



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

Re: [Monotone-devel] [Fwd: monotone_0.22-1_i386.changes ACCEPTED]

[Hendrik Boom]

On Wed, Aug 10, 2005 at 08:39:24PM -0700, Nathaniel Smith wrote:
> On Tue, Aug 09, 2005 at 11:39:28PM +0200, Tomas Fasth wrote:
> > Monotone version 0.22 has been accepted by the Debian installer
> > process and will shortly reach the Debian package archive for
> > unstable (etch).
> > 
> > I have updated the debian files in venge.net repository accordingly.
> > 
> > Nathaniel, when you build your -0.1 packages, are you then using a
> > sarge (stable) based Debian installation or something newer?
> 
> I'm using a very out-of-date unstable :-).  (I get lazy about
> upgrading my desktop...)

Any chance for a .deb for sarge?  sarge is stable enough for a server
that contains precious files, and unstable is, well, unstable.

-- hendrik


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

Re: [Monotone-devel] [Fwd: monotone_0.22-1_i386.changes ACCEPTED]

[Hendrik Boom]

On Mon, Aug 15, 2005 at 02:29:22PM +0200, Tomas Fasth wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Hello Nathaniel, Eric,
...
...>
> In general a backport to sarge (the current stable) should decrement
> the last digit by one and add "sarge1". A consecutive update should
> increment to "sarge2".
> 
> Example: "monotone_0.22-0.0sarge1_i386.deb".
> 
> I have a clean build environment for sarge (using pbuilder), so if
> you like I can provide a backport right after I have done the
> official upload to Debian unstable.

Thanks.  It'll be useful.

-- hendrik


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

Re: [Monotone-devel] monotone_0.22-1_i386.changes ACCEPTED

[Hendrik Boom]

On Tue, Aug 16, 2005 at 10:05:20AM +0200, Richard Levitte wrote:

> I don't keep track of the names, but if tesing == sarge, I can do it.  

At the moment, stable == sarge, and testing == etch.

-- hendrik



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

Re: [Monotone-devel] Proposal for human readable revision IDs

[Hendrik Boom]

On Tue, Sep 06, 2005 at 01:03:01PM +0100, Bruce Stephens wrote:
> Andy Jones <[EMAIL PROTECTED]> writes:
> 
> > How about the option to give a revision a "nickname"?  You might not
> > want to do this for all revisions you commit, but you might for the
> > ones you wanted others to pull.
> >
> > Seems to me that this is just a 'nickname' certificate, which would
> > be shown in moontone's normal completion, ls, status output if it
> > existed instead of (as well as?) the revision hash.
> 
> Something like a tag, you mean?  Only I guess you'd want it to be
> unique (multiple revisions can have the same tag).  
> 
> Only what happens if two people independently give the same nickname
> to two different revisions, and then their repositories are synced?

Either you allow two revisions to have the same nickname,
or you disambiguate by appending or prefixing the name of
whoever assigned the nickname
or you refuse to allow the sync without an explicit resolution of the problem.
Or you complain about ambiguioty when the nickname is used.

-- hendrik


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

Re: [Monotone-devel] Proposal for human readable revision IDs

[Hendrik Boom]

On Tue, Sep 06, 2005 at 10:36:28AM +0100, Bruce Stephens wrote:
> Thomas Haas <[EMAIL PROTECTED]> writes:
> 
> [...]
> 
> > Using the alphabet (A-Z, a-z) and the ten digits would reduce the
> > real estate from 40 to 27 characters.
> 
> That would be shorter, but would it be any more readable?

Only if you avoid using letters and digits that look like each other.
No 'O' 'o' 'l', for example.

-- hendrik


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

Re: [Monotone-devel] Re: Proposal for human readable revision IDs

[Hendrik Boom]

On Tue, Sep 06, 2005 at 04:53:30PM +0100, Bruce Stephens wrote:
> Andy Jones <[EMAIL PROTECTED]> writes:
> 
> [...]
> 
> > I don't think Monotone +can+ have incremental revisions, can it?  I
> > mean, suppose you and I both start by pulling revision 1.1 and then
> > make a change.  Don't we both get a different revision called 1.2?
> 
> It can have local incremental revisions, so for a specific database at
> a specific time, it can enumerate the DAG and produce a numbering (a
> numbering with useful meaning).  I think it could be made a stable
> enumeration, too (so a 2.7.1 revision in a particular database will
> always be 2.7.1).  

And if you had it traverse the database each tome you wanted
these numbers, and someday you decided to assign an explicit local name
"corundrum" to revision 2.7, henceforth, revision 2.7.1 could become
known as "corundrum.1"


> 
> I'm not sure whether that's useful enough to be worth doing (it still
> can't be global), but if someone coded it, I think it would be worth
> playing with, just to see.
> 
> 
> ___
> Monotone-devel mailing list
> Monotone-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/monotone-devel


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

Re: [Monotone-devel] Proposal for human readable revision IDs

[Hendrik Boom]

On Tue, Sep 06, 2005 at 04:00:02PM +0200, Thomas Haas wrote:

> I tried to describe my problem in my answer to Nathaniel. Short:
> Selectors do only work for revisions, not for other things, such as
> manifests and files. And, I find 40 byte hex strings hard to compare,
> match, and generally process.
> 

Putting spaces or other punctuation in the hash might help.
Say, after every eight characters?  Or as the crypto people used
to do, after every five?  Or an irregular pattern, to keep you eyes
from getting lost, like

   x xx xx-xx xx xx-xx xx

-- hendrik


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

Re: [Monotone-devel] Proposal for human readable revision IDs

[Hendrik Boom]

On Tue, Sep 06, 2005 at 10:17:32AM +0200, Thomas Haas wrote:

> Using the alphabet (A-Z, a-z) and the ten digits would reduce the real
> estate from 40 to 27 characters.

Or all or most of the 94 or so ASCII printable characters.

Using Japanese characters would reduce it even more.

Or the entire set of Unicode printable characters!  This might be *very*
good as a display representation, each ID would look *very* distinctive.
Believe me.  You might not know what to *call* a character, but you're not
likely to confuse a Georgian character with a Japanese or Sanskrit one.

You would need some way to get your display to give you a typable one
when you need it, but that might be a separate issue.

-- hendrik


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

Re: [Monotone-devel] "monotone cat file" not binary save?

[Hendrik Boom]

On Wed, Sep 07, 2005 at 03:00:30AM +0200, Richard Levitte - VMS Whacker wrote:
> In message <[EMAIL PROTECTED]> on Tue, 6 Sep 2005 14:27:23 -0700, Nathaniel 
> Smith <[EMAIL PROTECTED]> said:
> 
> njs> It's definitely not an intentional feature of 'cat'.  However,
> njs> it's possible that it's some unavaoidable win32 bogosity, like
> njs> stdout being provided as a text-mode descriptor that is
> njs> inherently lossy or something...
> 
> As most other operating systems that have a line endine sequence other
> than NL, I think Windows C library *correctly* does NL->CRNL
> conversion on stdout unless you somehow explicitely tell it that the
> output should remain unconverted.

I believe you mean LF instead of NL.

Historical note:

LF -- LineFeed - is ASCII character
0x0a, (Unicode u000a), and has traditionally meant moving vertically
downward to the next line, preserving horizontal position.  CR meant
carriage return, which was to move to the beginning of the same line.
So on the old TTYs which were still prevalent on the 60's (and were
probably much older), starting a new line was CR-LF.  The CR was first
because it took time to move teh carriage all that much and the LF gave
the TTY time to finish returning the carriage.

It was Unix, and C, I believe, that started the perversion of using
LF to mean CR-LF.  The relevant standard of the time specified that
so simplify keyboarding, input routines could interpret a single keystroke
as CR-LF.  But it was the more natural CR that was to be the single
keystroke, not LF.

There *has* been a NextLine character defined in the course of time,
but I've never seen it used.  It's 0x85, Unicode u0085, and it's name is
Next Line, abbreviated NEL.

End of historical note.

I usually read my text files in binary, and recognise either CR of LF as
meaning end-of-line, and ignore a CR after a LF of a LF after a CR.

Output is always a platform-dependent hassle, however.

-- hendrik


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

Re: [Monotone-devel] Re: Proposal for human readable revision IDs

[Hendrik Boom]

On Fri, Sep 09, 2005 at 12:47:48AM +0200, Lapo Luchini wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> What makes me chuckle with an evil grin in this discussion is that
> probably the use of hash values in monotone was one of the main features
> that convinced me it was more "worth trying" then the other distributed
> ones ;-)

It was its totally distributed nature that convinced me. not the hash codes.
I would have been happier with some locally unique version name that is
combined with a globally unique tag identifying the site at which the
locally unique name was created.  The reason is that I am still
paranoid about losing emtire files by hash collisions.

In fact, in this discussion about readable hash codes, we're reinventing
variations on this kind of mechanism.

While I do use hash codes for speed in many situations, I always back them
up with another. theoretically correct mechanism.

-- hendrik


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

Re: [Monotone-devel] A Two-Fold Proposal: On Formats And Front-Ends

[Hendrik Boom]

On Tue, Oct 04, 2005 at 04:21:26AM -0700, Larry Hastings wrote:
> 
> 
> I have for you two separate but intimately related proposals, and I'm 
> going to describe them in reverse order of implementation because it 
> flows better.  Keep in mind, I'm still quite wet-behind-the-ears with 
> respect to Monotone; I typed my first *monotone* command less than two 
> weeks ago.  It wouldn't surprise me if this was all a bad idea for any 
> number of unforseen reasons.  And yet I bravely post, having read 
> somewhere that the *monotone* community is "friendly".  So... be kind.  :)
> 
> 
> Right now *monotone* makes life tough for front-end developers.  The 
> main problem I see is the N different output/file formats of *monotone*, 
> where N is /distressingly/ large:

I'm all for uniformity in configuration file formats.  Maybe this should
be on the list, too?  Every Linux program seems to have a different
configuration file format.

> [...]
> 
> To me the solution is clear, and it is here we arrive at my first actual 
> proposal: separate /presentation/ from /application logic/ by breaking 
> the current *monotone* executable into two pieces.  One piece would be 
> the "engine" that did all the actual work.  The second piece would be 
> the "front-end", or "driver", which drives the *monotone* engine (as gcc 
> drives the front-end, back-end, and linker).  The driver would provide 
> the command-line interface of the current *monotone* executable, convert 
> internal messages to their user-friendly localized equivalents, etc.  
> The communication between the two would be done over pipes in some 
> easy-to-cope-with data specification.

Would (multiple) front-end(s) and a shared engine library do?
It's possible you might get more efficient communications between the
front and back ends that way.  And if you really want a pipe, one of
the front ends could handle it.  Of course you'd end up having to
worry about that drastic differences in the ways different OS's
handle their shared libraries.

> 
> This has many advantages:
> 
> [...]
>
>* If you ship file data over the pipes, and restrict the engine to
>  so the only file it talks to is the database, bingo!  Throw ssh
>  around it and now you have client-server *monotone*.  If you were
>  just a little bit more careful, you could even have multiple
>  computers all sharing the same database, each with just their own
>  working copies rather than their own full-blown *monotone*
>  databases.  (Though I gather this is strongly discouraged.)  The
>  back-end could be written to accept() on a socket directly, and
>  run as a daemon in the background, thus allowing people to run
>  *monotone* in a traditional client-server mode if they so chose. 
>  We might even be able to fold push/pull/sync into this same
>  socket, making database synchronization even more effortless.

I'd be quite happy to have only *one* monotone database on each machine.
At present I seem to have a monotone server that's permanently availiable
over my LAN, and another personal database that I use and regularly sync with 
the server.  (my personal files are also on the same server).
> 
> A moment ago I handwaved what "data representation" I had in mind.  I 
> propose there are three main candidates: XML, ASN.1, and JSON.  I will 
> immediately dispense with the first two, and show why the third is far 
> more likely.  :)
> 
>* How can I automatically cull XML from the running?

XML is doomed to succeed.  That being said, it's not clear we have to use it.
Aside from its historically acquired complexity, it makes one fatal mistake:
it fails to distinguish a type from a field-selector.
> 
>* What about ASN.1?

ASN.1 makes the same fatal mistake.  But there's one thing it does right:
YOu can encode it in such a way that every nested phrase is prefixed with
its length.  This makes it possible to tree-walk through an ASM file
without parsing the parts one is not interested it.

>  Well, have you /looked/ at some ASN.1?  It has
>  none of XML's effervescent charm.  It's more parsimonious than
>  XML, but then what data encapsulation format is not?  Its biggest
>  failing: it looks to be wholly inflexible.  We couldn't add new
>  fields without creating a new grammar, which would break tools
>  that didn't upgrade their grammar.  I say screw it .

ASN.1 can be parsed without a grammar to derive its tree structure.
You won't know what any of the values at the leaves of the tree are,
though, and if you have an aggregate, you may not know the semantics
of the particular aggregator you have.  And if you are willing to
ignore type-identifiers that you happen not to understand, you can
still process the rest.

> 
> On the other hand, I first heard of JSON by reading a *monotone* IRC log 
> somewhere, wherein Mr. Hoare hisself said "[his] money's on JSON for 
> this sort of task":
>
> http://www.loglibrary.com/show_page/view/106?

[Monotone-devel] I need a better diff

[Hendrik Boom]

I gather that monotone uses a better file-differencing algorithm
than the widely known one distributed as diff -- for one thing,
it can handle binary files.

I'm in the position of needing a better diff -- I have multiple versions
of text files. I need to compare them, and of course diff is led hopelessly
astray by the fact that small changes in a paragraph have caused line
breaks to move to different places.  Since many typos have been corrected
between versions (I don't even know which versins are newer), there is
little for diff to synchronise on although the files are very similar,
except for blank lines, which does no good at all and just leads it further 
astray.

Could you tell me what algorithm your file comparison uses?
And where to find a reusable implementation?

-- hendrik


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

Re: [Monotone-devel] Re: Feature request: monotone grep

[Hendrik Boom]

On Tue, Nov 08, 2005 at 06:34:09PM +, Bruce Stephens wrote:
> Shaun Jackman <[EMAIL PROTECTED]> writes:
> 
> > 2005/11/8, Bruce Stephens <[EMAIL PROTECTED]>:
> 
> [...]
> 
> >> I'd worry that people would want to use other flags of grep, and
> >> then where do you stop?
> >
> > I think the same argument can be made of `montone diff', but it's
> > such a useful task that some basic form of the command within
> > monotone would be a benefit. Most of the time I call GNU grep simply
> > as `grep', so I wouldn't worry terribly about the extra options.

Occasionally I go so far as to specify -i

> 
> I imagine it's as much expectations as utility.  I expect to be able
> to do "diff", but I don't expect to be able to grep through versions
> of files.  Maybe some SCMs provide that, and I just happen not to have
> used those?
> 
> [...]
> 
> > Perhaps there should be a standard way for monotone to call out to
> > helper scripts, where `monotone grep', for example calls out to the
> > script `monotone-grep' -- in /usr/share/monotone/bin or the path if
> > that fails -- with all the necessary information provided on the
> > command line and in the environment.
> 
> That idea came up before, and didn't get much support, IIRC.  I think
> a problem is that everyone's monotone could be different, so it's
> difficult to document and support, and there's the potential of
> clashing command names and things.
> 
> On the other hand, Mercurial and Bazaar-ng have that kind of thing,
> and I imagine it works well enough for them.  Maybe things are
> different now?

I guess one thing to consider is whether a script-calling feature
like this will forestall a lot of niggly feature requests.
Or are lua-hooks enough?

-- hendrik



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

Re: [Monotone-devel] Certificates on certificates?

[Hendrik Boom]

On Sun, Nov 20, 2005 at 09:50:54PM +0100, Richard Levitte - VMS Whacker wrote:
> In message <[EMAIL PROTECTED]> on Sun, 20 Nov 2005 20:57:53 +0100, Tom 
> Koelman <[EMAIL PROTECTED]> said:
> 
> tkoelman> an idea that I just got is this: wouldn't it be nice to be
> tkoelman> able to attach certificates to certificates?
> 
> My brain just went into an endless loop thinking about it.  Gotta go
> for repairs :-).
> 
> Seriously, it kind of sounds like a good idea, but I wonder how far we
> should go with that, as it seems it could be generalised to madness,
> and I'm not sure we should do that.

W3 (the people that do the web standards) went in this direction
with RDF, their Resource Description Framework.  I don't *think*
it's madness (except that it uses XML syntax), but I'm not entirely
sure.

-- hendrik


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

[Monotone-devel] Re: question about mtn cvs_import

[Hendrik Boom]

On Sat, 11 Apr 2009 19:07:07 -0400, hendrik wrote:

> With the command
> 
>mtn cvs_import pathname
> 
> does pathname need to be the name of a file or directory on the locel
> system, or is there come convention that allows mtn to use a remote cvs
> repository accessible over the network using, say, anonymous CVS login?
> 
> -- hendrik

Or maybe what rsync command might fetch it?

-- hendrik



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

[Monotone-devel] Re: question about mtn cvs_import

[Hendrik Boom]

On Sun, 12 Apr 2009 02:38:16 +, Hendrik Boom wrote:

> On Sat, 11 Apr 2009 19:07:07 -0400, hendrik wrote:
> 
>> With the command
>> 
>>mtn cvs_import pathname
>> 
>> does pathname need to be the name of a file or directory on the locel
>> system, or is there come convention that allows mtn to use a remote cvs
>> repository accessible over the network using, say, anonymous CVS login?
>> 
>> -- hendrik
> 
> Or maybe what rsync command might fetch it?

I should go to bed.  I forgot to say what IT is, and I should have posted 
to a different mailing list.  I still want to know about pathname with 
mtn import cvs, but I don't expect anyone here to tell me where to find 
the Modula 3 source repositories Sorry for waste of bandwidth.  Going 
to bed now.

-- hendrik




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

[Monotone-devel] Re: Text under revision control

[Hendrik Boom]

On Thu, 05 Mar 2009 13:05:29 -0800, Zack Weinberg wrote:

> On Thu, Mar 5, 2009 at 11:16 AM,   wrote:
>> On Thu, Mar 05, 2009 at 09:57:06AM -0800, Zack Weinberg wrote:
>>> I'm not actually sure whether the default three-way content merge is
>>> line-oriented or byte-oriented.
>>
>> Would the following be an effective test?
>>
>>               A
>>              / \
>>             /   \
>>            B     C
>>
>> where B and C involve changes in different parts of the same line, and
>> then try to merge B and C to see if there's a merge conflict?
> 
> Yeah, I think so.
> 
> Before you go and add stuff to the test suite, please look through the
> existing set of Lua testcases with "merge" in their name.  It might
> already be there.  (I'll hand out fabulous no-prizes for fixing existing
> xfailed tests... ;-)
> 
> zw

I finally got around to performing the test, using nonoverlapping changes 
in one line.  B had a change near the beginning of the line; C had 
changes near the end of the line.  When merging the two heads, monotone 
detected a conflict and it had to be resolved manually.

So.  Monotone does appear to merge on a line-by-line basis.

Too bad for OpenOffice's .fodt file type.

-- hendrik



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

[Monotone-devel] Re: cvs_import failure

[Hendrik Boom]

On Mon, 28 Dec 2009 12:40:46 +0100, Michael Haggerty wrote:

> Daniel Carosone wrote:
>> The latter seems to be of the most general utility, given current
>> volumes and efforts of other projects (assuming the format contains
>> what we need and isn't completely horrible).
> 
> The git-fast-import format is quite good and well-documented [1].
> 
> Markus Wanner wrote:
>> Note that git has the ability to represent more than two ancestors for
>> a merged revision, which monotone does not. Not that it's an often used
>> feature, but IIRC cvs2git is one of its users. (I vaguely remember
>> discussing these issues with Michael Haggerty, author of cvs2svn. See
>> that project's mailing list).
> 
> cvs2svn/cvs2git etc. has a setting to limit merges to two parents.  So
> this should not be a problem.
> 
> hend...@topoi.pooq.com wrote:
>> with all these cvs2* programs around, it might be useful to isolate
>> their common core (the cvs part and the 2 part) from the * part.
>> Incresed modularity.  ANy chance that such factoring would spread to
>> the others and overall maintenance costs?
> 
> These programs (cvs2svn, cvs2git, cvs2bzr, and cvs2hg) are all part of
> the cvs2svn project [2] and share 90% of their code (namely the hard
> part, which is figuring out the CVS history).

Then this set of programs looks like one good place to start.  Are they 
each one-shot conversions, or can they update the target repository if 
things are still being checked into the CVS repository?  One thing I.m 
cinvinced of is that not everyone will be ready to check in their works-
in-progress simultaneously.

First step would seem to be to look at those two references.
 

> 
> Michael
> 
> [1] http://www.kernel.org/pub/software/scm/git/docs/git-fast-import.html
> [2] http://cvs2svn.tigris.org/

Aha!  Isn't tigris.org the place to find software that automatically 
chops big test cases into small ones?

-- hendrik

P.S.  Reply to the mailing list, not to me;  my email is down at the 
moment, and I'm reading this via usenet and gmane,





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

[Monotone-devel] Re: cvs_import failure

[Hendrik Boom]

On Fri, 01 Jan 2010 19:45:25 +0100, Markus Wanner wrote:
> Hendrik Boom wrote:
> 
>> Aha!  Isn't tigris.org the place to find software that automatically
>> chops big test cases into small ones?
> 
> tigris.org hosts subversion up until now. IIRC it is about to be handed
> over to the Apache foundation.

I found the file-chopping site: http://delta.tigris.org/

-- hendrik



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

[Monotone-devel] Re: cvs_import failure

[Hendrik Boom]

On Fri, 01 Jan 2010 19:45:25 +0100, Markus Wanner wrote:

> Hi,
> 
> Hendrik Boom wrote:
>> Then this set of programs looks like one good place to start.  Are they
>> each one-shot conversions, or can they update the target repository if
>> things are still being checked into the CVS repository?
> 
> AFAIK cvs2svn is still a one-shot conversion tool. However, if you don't
> mess around with your CVS repository, subsequent imports should work as
> well.

The question here is whether the proposed cvs2mtn, on repeated use, would 
produce monotone repositories that could be synced.  I suspect not.

> 
> (I don't see how one could handle continuous imports in case the
> underlying CVS is changed manually anyway. And yes, this happens more
> frequently than you think).
> 
There's free software, cvsup, that maintains a local copy of a remote CVS 
repository.  It might have some ideas that could contribute to a 
continuous update, but I don't know how it deals with manual mangling 
either.

I suspect that getting any conversion is more important than getting an 
ongoing continual update working.  But it's possible thinking about the 
problem will generate some ideas.  I'll keep it in mind when I start 
reading existing code.

-- hendrik



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

[Monotone-devel] Re: cvs_import failure

[Hendrik Boom]

On Sat, 02 Jan 2010 11:34:15 +0100, Markus Wanner wrote:

> Hello Hendrik,
> 
> Hendrik Boom wrote:
>> The question here is whether the proposed cvs2mtn, on repeated use,
>> would produce monotone repositories that could be synced.  I suspect
>> not.
> 
> As long as you only *add* commits to the source CVS repository, that
> should not be much of an issue. Do a new conversion to monotone and sync
> with the existing monotone repository.

Well, it's possible the topological analysis of the CVS repository could 
generate a different graph if a few entries have been added.  Especially 
if it uses time stamps to determine which changes go together.  The graph-
theoretic analysis seems chaotic to me (in the sense that small changes 
could have large effects).

> 
>> There's free software, cvsup, that maintains a local copy of a remote
>> CVS repository.  It might have some ideas that could contribute to a
>> continuous update, but I don't know how it deals with manual mangling
>> either.
> 
> Lots of places use rsync instead of cvsup nowadays. However, I don't
> think that has much to do with continuous updates. The issues for that
> feature are:
> 
>  * being able to determine what RCS versions the single files of the
> head in monotone (i.e. the last imported version) are. Then continue to
> import from there, if there are any new commits.
> 
>  * figuring out, if there are changes in CVS to revisions that have
> already been imported.
> 
>> I suspect that getting any conversion is more important than getting an
>> ongoing continual update working.  But it's possible thinking about the
>> problem will generate some ideas.  I'll keep it in mind when I start
>> reading existing code.
> 
> I've already discussed this topic with Christoph Petig, author of
> cvssync (check the refactored branch for most up to date code). We
> figured it's necessary to track the RCS version for each file included
> in a revision to be able to determine a point to continue from.

Those are the data you need, yes.  It's conceivable you could deriv some 
of this by recomputing the hash-codes for every file and comparing with 
those of the monotone repository, but that could be time-consuming.  Not 
what you want to do over a network link to a CVS repository.  Probably OK 
for a local one.  I wonder how cvsup does it.

> That's quite a bit of meta-data, which rarely changes. Storing that
> information as part of a certificate would get you a lot of certificate
> data, which is not delta compressed. Instead I've proposed to implement
> "vanishing attributes", however, the use case for those is pretty
> limited.
> 
> So what we came up with (at the Mountain View summit, IIRC) is a
> combination: store the origin RCS versions as attributes, these are
> delta compressed and don't take up much space if they remain unchanged.
> To differentiate a descendent revision which doesn't originate from CVS
> (but "accidentally" retains the RCS version attribute)

Is that what the vanishing attributes were for?

> we want to put an
> additional cert on the revision that really originates from CVS.

Are these certs somehow more space-efficient than storing the CVS 
versions in the certs?
 
> That
> way we use the existing infrastructure (attributes and certs) and don't
> need to implement anything, but still profit from delta compression of
> that information.
> 
> I've implemented the addition of attributes and certs (in
> cvs_import-branch-reconstruction), but not the reading back of that
> information for contiguous imports. I don't know about the status of
> that for cvssync.

We seem to have several attempts to implement cvs interaction.  There's 
cvs_import-branch-reconstruction, and there's cvssync.  And there's a 
suggestion to start anew by modifying cvs2svn,  Are these related in any 
way?  Are they on separate branches?  Do any of them somewhat work?

My mental image right now is of modifying some kind of a cross between 
cvsup and cvs2svn to use monotone's automate interface to interact with 
the cert and attribute infrastructure ... but I fear mthat Modula 3 and 
python may argue on a fundamental level.  It might be a better 
algorithmic model than an implementation plan.

Thanks

hendrik





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

[Monotone-devel] Re: removal of packet functions

[Hendrik Boom]

On Wed, 11 Aug 2010 10:17:29 -0400, John Bailey wrote:

> 
> If a user has no netsync access to *any* public netsync server, how does
> this solve, or even help, his problem?  As I mentioned above, netsync
> via SSH is not a viable solution to this scenario.
> 

There's always the mechanism of putting the diffs on a USB stick or even 
a floppy disk, putting it in an paper (or maybe cardboard) envelope, 
putting a stamp in it, and mailing it.

Receiver, if suitably paranoid, could clone the main mtn database and 
apply the diffs or packets or whatever to *it*, in quarantine if necesary.

This does presume mtn will accept the changessets via packet, though.

-- hendrik


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

Re: [Monotone-devel] changelog editor issues

[Hendrik Boom]

On Sat, Sep 11, 2010 at 02:10:25AM +0100, Francis Russell wrote:
> Stephen Leake wrote:
> >>
> >> "Certificate values may be modified"
> > 
> > Actually, I don't think "certificate" is a common term for this; I'd
> > prefer:
> > 
> > -- Fields below may be modified --
> 
> >From the parsing perspective, field does make more sense. However, in
> the end, all the fields do become certificates which is a crucial part
> of the monotone model and what monotone calls them. Anyone using
> monotone is eventually going to have to understand certificates.
> Regardless of what the help text calls them, I think their purpose is
> obvious.

I don't care (at the moment) whether it's fields or certificates, but I 
think it should be clear whether the user or the system will be 
modifying fields.  Perhaps

-- You may modify the fields below --

-- hendrik


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

Re: [Monotone-devel] tracking upstream

[Hendrik Boom]

On Tue, Sep 21, 2010 at 06:45:44AM -0500, Timothy Brownawell wrote:
> On 09/21/2010 03:15 AM, Thomas Keller wrote:
>> Instead of disapproving J with K one could also try to suspend J and
>> branch off on one of its parents. I have to admit though that I'm unsure
>> if monotone keeps the suspended branch and its revision(s) in your local
>> database only or if they would be transferred to other nodes still,
>> leading to the similar / unwanted side effect that people might see the
>> unwanted change (if they decide to take a close look).
>
> Suspended branches/microbranches still get transferred in netsync, it  
> just grabs everything with a matching branch cert.

Which does suggest you might be able to limit spread by adjusting the 
list of branches that monotone is allowed to sync.

-- hendrik

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

Re: [Monotone-devel] A few message seem a bit... confusing

[Hendrik Boom]

On Sun, Oct 24, 2010 at 08:41:18PM +0200, Richard Levitte wrote:
> Hey,
> 
> I'm currently translating new strings to Swedish, and I'm noticing a
> few things that seem, at the very least, confusing...
> 
> 1. URL/URI: in some messages, we say URL and in others, we say URI.
>I'd suggest going for one of them, not both.

URLs and URIs are different things.  Do we distinguish them and use them 
appropriately, or are we playing at elegant variation?

-- hendrik

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

Re: [Monotone-devel] Time for 0.99

[Hendrik Boom]

On Sun, Oct 24, 2010 at 10:56:16PM +0200, Thomas Keller wrote:
> 
> Yes, always the evening :) Thursday sounds fine to me as well. I really
> just want to get my ass off and do it not much later than that, because
> more and more people are bitten by the SQLite 3.7.3 bug, which might
> force us to do a 0.48.2 if it takes much longer.

I hope the patch to make it work with 3.7.3 doesn't make it stop working 
with earlier sqlites (such as the ones I use from Debian testing and 
stable, that still have the bug you're working around).

-- hendrik

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

[Monotone-devel] usher installation

[Hendrik Boom]

Would there be documentation around for the installation, care, and 
feeding of usher?

-- hendrik


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

[Monotone-devel] server move?

[Hendrik Boom]

On page http://wiki.monotone.ca/SelfHostingInfo/

it says to

mtn --db=mtn.db pull monotone.ca "net.venge.monotone*

But when I try it, (trying to update my own database which is called
monotone.db instead of mtn.db) I get

hend...@april:~/monotone$ mtn --db=monotone.db pull monotone.ca 
"net.venge.monotone*"
mtn: doing anonymous pull; use -kKEYNAME if you need authentication
mtn: connecting to monotone.ca
mtn: Received warning from usher: No server for host 'monotone.ca' or 
pattern 'net.venge.monotone*'
mtn: error: I/O failure while talking to peer monotone.ca, disconnecting
hend...@april:~/monotone$

Evidently the master database isn't where it used to be.  Replacing 
monotone.ca by code.monotone.ca (a wild guess) doesn't seem to help.

I'm running this on 64-bit Debian lenny, using 
monotone 0.40 (base revision: 5ccc279f9dea0444b47f03dd5291ecc985fcb7f6)
so I shouldn't be having trouble with sqlite.

Where has it moved, or, what else have I done wring?

-- hendrik


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

Re: [Monotone-devel] server move?

[Hendrik Boom]

On Sun, Oct 31, 2010 at 09:57:44PM +0100, Richard Levitte wrote:
> You're entirely correct, the information on that page is incorrect.
> 
> If you run mtn 0.48 (or possibly older, haven't really tried), this
> will work:

mtn 0.40 fails to recognise mtn:

hend...@april:~/monotone$ mtn --db=monotone.db pull 
mtn://monotone.ca/monotone "net.venge.monotone*"
mtn: doing anonymous pull; use -kKEYNAME if you need authentication
mtn: connecting to mtn://monotone.ca/monotone
mtn: network error: service name resolution failed for: mtn
hend...@april:~/monotone$ 

and on my machine that's reasonably up-to-date I already have the toxic 
version of sqlite.
> 
> mtn --db=mtn.db pull mtn://monotone.ca/monotone "net.venge.monotone*"
> 
> If you run mtn 0.99 (or newer when the time comes), the following
> syntax should be used:
> 
> mtn --db=mtn.db pull "mtn://monotone.ca/monotone?net.venge.monotone*"
> 
> We're going to change the information on the page you read as soon as
> possible (there are a number of things that are high prio right now)

So I guess that I'll have to wait for 0.99.1.  I gather that's one of 
the high prio items.  Hmm.  Maybe 0.99 will work on my less up-to-date 
machine.  I'll try that if I turn out not to be able to wait.

Thanks.

-- hendrik

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

Re: [Monotone-devel] server move?

[Hendrik Boom]

On Sun, Oct 31, 2010 at 10:27:49PM +0100, Ludovic Brenta wrote:
> 
> Hendrik Boom wrote:
> > On Sun, Oct 31, 2010 at 09:57:44PM +0100, Richard Levitte wrote:
> >> You're entirely correct, the information on that page is incorrect.
> >> 
> >> If you run mtn 0.48 (or possibly older, haven't really tried), this
> >> will work:
> > 
> > mtn 0.40 fails to recognise mtn:
> 
> The entry for monotone is absent from /etc/services on Debian.  Try this:
> 
> mtn --db=monotone.db pull 4691://monotone.ca/monotone
> "net.venge.monotone*"

That worked nicely.

Thanks.

-- hendrik


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

Re: [Monotone-devel] server move?

[Hendrik Boom]

On Sun, Oct 31, 2010 at 10:32:22PM +0100, Thomas Moschny wrote:
> Am Sun, 31 Oct 2010 17:15:29 -0400
> schrieb Hendrik Boom :
> 
> > On Sun, Oct 31, 2010 at 09:57:44PM +0100, Richard Levitte wrote:
> > > You're entirely correct, the information on that page is incorrect.
> > > 
> > > If you run mtn 0.48 (or possibly older, haven't really tried), this
> > > will work:  
> > 
> > mtn 0.40 fails to recognise mtn:
> > 
> > hend...@april:~/monotone$ mtn --db=monotone.db pull 
> > mtn://monotone.ca/monotone "net.venge.monotone*"
> > mtn: doing anonymous pull; use -kKEYNAME if you need authentication
> > mtn: connecting to mtn://monotone.ca/monotone
> > mtn: network error: service name resolution failed for: mtn
> 
> Try mtn --db=monotone.db pull \
>   monotone://monotone.ca/monotone "net.venge.monotone*"
> instead, or add an entry for mtn to /etc/services.

It turns out there's no entry for mtn or monotone in Debian lenny.
But using the number explicitly worked fine.

-- hendrik

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

Re: [Monotone-devel] server move?

[Hendrik Boom]

On Sun, Oct 31, 2010 at 10:39:00PM +0100, Thomas Moschny wrote:
> Hendrik Boom :
> 
> > So I guess that I'll have to wait for 0.99.1.  I gather that's one of 
> > the high prio items.  Hmm.  Maybe 0.99 will work on my less
> > up-to-date machine.  I'll try that if I turn out not to be able to
> > wait.
> 
> Forgot to add this: You can always use the stand-alone binaries from
> the monotone.ca download page. They don't need to be installed (just
> bunzip and copy to $PATH) and should work on any x86 Linux where a
> 32bit glibc 2.3 (or later) is available. They don't need any other
> libraries.

Does that mean it's statically linked with a nontoxic version of 
sqlite?

-- hendrik

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

Re: [Monotone-devel] server move?

[Hendrik Boom]

On Sun, Oct 31, 2010 at 11:00:26PM +0100, Thomas Moschny wrote:
> Hendrik Boom :
> 
> > > Forgot to add this: You can always use the stand-alone binaries from
> > > the monotone.ca download page. They don't need to be installed (just
> > > bunzip and copy to $PATH) and should work on any x86 Linux where a
> > > 32bit glibc 2.3 (or later) is available. They don't need any other
> > > libraries.
> > 
> > Does that mean it's statically linked with a nontoxic version of 
> > sqlite?
> 
> The latest binaries there are linked against sqlite 3.5.9.

That's good.  Even if Debian insists you leave their package 
promiscuously open to strange libraries, there's no reason to do it with 
your own executables!

-- hendrik

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

Re: [Monotone-devel] [ANNOUNCE] monotone 0.99.1 released

[Hendrik Boom]

On Sun, Oct 31, 2010 at 11:27:04PM +0100, Thomas Keller wrote:
> 
> The release can be downloaded at the usual location [0]. Sorry for the
> recent release flood, we promise to cool now for a while...

No need to apologise.  I'd much rather have a working system than have 
you ration releases.

-- hendrik

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

Re: [Monotone-devel] usher 0.99 release (name-based virtual hosting for monotone)

[Hendrik Boom]

On Sat, Nov 06, 2010 at 06:36:38AM +0100, Richard Levitte wrote:
> This is a piece of software I'd like to see debianised...
> 
> I see there's an ld debian branch...

I wonder whether it should be a replacement for 
monotone-server.  In function, if not in name.

-- hendrik

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

Re: [Monotone-devel] usher 0.99 release (name-based virtual hosting for monotone)

[Hendrik Boom]

On Fri, Nov 05, 2010 at 11:46:03PM -0500, Timothy Brownawell wrote:
> There is an actual release of usher available now. It's tagged as
> usher-0.99 available from
>mtn://monotone.ca/contrib?net.venge.monotone.usher

This is what I've been waiting for!  But my browser had other ideas ...

> You can also browse the source at
>http://code.monotone.ca/p/contrib/source/tree/t:usher-0.99/
> and see the documentation at
>
> http://code.monotone.ca/p/contrib/source/file/t:usher-0.99/doc/documentation.html

Whe I enter this URL into my iceweasel browser, it tell me:

You have chosen to open

   * documentation.html

 which is a: HTML Text
 from: http://code.monotone.ca

What should iceweasel do with this file?

* Open with [ /usr/bin/galeon (default) ]
* Save File
* Do this automatically for files like this from now on.

 [ X cancel ] [ OK ]

The drop-down menu that suggests using galeon (another browser) 
presents me to choose between
   [ /usr/bin/galeon (default) ]
and
   Other...

Is this weird, or what?  Iceweasel not knowing what to do with HTML?  
And suggesting handing it over to another browser?


Well, I did download the tarball, 

>http://mtn-host.prjek.net/projects/webhost/files/usher-0.99.tar.gz

and untarred it.  The README file says 

The documentation is in doc/documentation.html.

But there is no doc directory to be found in the tarball.

Of course, when in the browser I select 'save file' and tell it where to 
put it, it saves it away nicely.  Then iceweasel has no trouble showing 
me the contents of the saved file, which appears to be -- what else? -- 
documentation!

-- hendrik

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

Re: [Monotone-devel] usher 0.99 release (name-based virtual hosting for monotone)

[Hendrik Boom]

On Fri, Nov 05, 2010 at 11:46:03PM -0500, Timothy Brownawell wrote:
> There is an actual release of usher available now. It's tagged as
> usher-0.99 available from
>mtn://monotone.ca/contrib?net.venge.monotone.usher
> and there is a tarball available at
>http://mtn-host.prjek.net/projects/webhost/files/usher-0.99.tar.gz
> . It works on at least Debian and FreeBSD.
> 
> You can also browse the source at
>http://code.monotone.ca/p/contrib/source/tree/t:usher-0.99/
> and see the documentation at
>
> http://code.monotone.ca/p/contrib/source/file/t:usher-0.99/doc/documentation.html

I guess now comes the inevitable flood of stupid questions as i try to 
make sense of the documentation.

I'm not clear what happens to authentication.  Have I messed something?

The example configuration has the line

monotone"mtn" "-k" "my_key"

This suggests to me that the various monotones in the herd are going to 
be performing actions fot the user whose key is "my_key".  What happens 
to the identity of the remote user who is initiating the sync operation? 

-- hendrik

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

Re: [Monotone-devel] usher 0.99 release (name-based virtual hosting for monotone)

[Hendrik Boom]

On Fri, Nov 05, 2010 at 11:46:03PM -0500, Timothy Brownawell wrote:
> There is an actual release of usher available now. It's tagged as
> usher-0.99 available from
>mtn://monotone.ca/contrib?net.venge.monotone.usher
> and there is a tarball available at
>http://mtn-host.prjek.net/projects/webhost/files/usher-0.99.tar.gz

I did the ./configure, and make, and then I did make test
I got a lot of stuff that looked like errors, but I suspect that the 
complete test environment wasn't available on my system.  I don't, to my 
knowledge, have a server mtn://127.0.0.1:8691/prjek-s?net.prjek.separate
or is that something the test scripts should have set up?

> . It works on at least Debian and FreeBSD.

Using a Debian stable running on a 64-bit AMD64.

-- hendrik
make  check-TESTS
make[1]: Entering directory `/farhome/hendrik/dn/usher/usher-0.99'
TESTDIR=/farhome/hendrik/dn/usher/usher-0.99/test-dir
Running test test1...
Copying scripts...
scripts
scripts/foobar.sh
bound to 127.0.0.1:23345
bound to 127.0.0.1:8691
Testing: serve example 127.0.0.1:25436
Testing: multipull 3 mtn://HOST/prjek-s?net.prjek.separate
mtn: misuse: database 
/farhome/hendrik/dn/usher/usher-0.99/test-dir/test1/example.mtn does not exist
mtn: setting default server to mtn://127.0.0.1:8691/prjek-s?net.prjek.separate
mtn: setting default branch include pattern to 'net.prjek.separate'
mtn: setting default branch exclude pattern to ''
mtn: doing anonymous pull; use -kKEYNAME if you need authentication
mtn: connecting to mtn://127.0.0.1:8691/prjek-s?net.prjek.separate
mtn: Received warning from usher: No server named 'prjek-s?net.prjek.separate'
mtn: error: I/O failure while talking to peer 
mtn://127.0.0.1:8691/prjek-s?net.prjek.separate, disconnecting
mtn: setting default server to mtn://127.0.0.1:8691/prjek-s?net.prjek.separate
mtn: setting default branch include pattern to 'net.prjek.separate'
Testing: multipull 3 'mtn://HOST/prjek?net.prjek.{fnord,foobar}'
mtn: setting default branch exclude pattern to ''
mtn: doing anonymous pull; use -kKEYNAME if you need authentication
mtn: connecting to mtn://127.0.0.1:8691/prjek-s?net.prjek.separate
mtn: Received warning from usher: No server named 'prjek-s?net.prjek.separate'
mtn: error: I/O failure while talking to peer 
mtn://127.0.0.1:8691/prjek-s?net.prjek.separate, disconnecting
mtn: setting default server to mtn://127.0.0.1:8691/prjek-s?net.prjek.separate
mtn: setting default branch include pattern to 'net.prjek.separate'
mtn: setting default branch exclude pattern to ''
mtn: doing anonymous pull; use -kKEYNAME if you need authentication
mtn: connecting to mtn://127.0.0.1:8691/prjek-s?net.prjek.separate
mtn: Received warning from usher: No server named 'prjek-s?net.prjek.separate'
mtn: error: I/O failure while talking to peer 
mtn://127.0.0.1:8691/prjek-s?net.prjek.separate, disconnecting
mtn: setting default server to 
mtn://127.0.0.1:8691/prjek?net.prjek.{fnord,foobar}
mtn: setting default branch include pattern to 'net.prjek.{fnord,foobar}'
mtn: setting default branch exclude pattern to ''
mtn: doing anonymous pull; use -kKEYNAME if you need authentication
mtn: connecting to mtn://127.0.0.1:8691/prjek?net.prjek.{fnord,foobar}
mtn: Received warning from usher: No server named 
'prjek?net.prjek.{fnord,foobar}'
mtn: error: I/O failure while talking to peer 
mtn://127.0.0.1:8691/prjek?net.prjek.{fnord,foobar}, disconnecting
mtn: setting default server to 
mtn://127.0.0.1:8691/prjek?net.prjek.{fnord,foobar}
mtn: setting default branch include pattern to 'net.prjek.{fnord,foobar}'
mtn: setting default branch exclude pattern to ''
mtn: doing anonymous pull; use -kKEYNAME if you need authentication
mtn: connecting to mtn://127.0.0.1:8691/prjek?net.prjek.{fnord,foobar}
mtn: Received warning from usher: No server named 
'prjek?net.prjek.{fnord,foobar}'
mtn: error: I/O failure while talking to peer 
mtn://127.0.0.1:8691/prjek?net.prjek.{fnord,foobar}, disconnecting
Testing: multipull 3 mtn://HOST/example?org.example
mtn: setting default server to 
mtn://127.0.0.1:8691/prjek?net.prjek.{fnord,foobar}
mtn: setting default branch include pattern to 'net.prjek.{fnord,foobar}'
mtn: setting default branch exclude pattern to ''
mtn: doing anonymous pull; use -kKEYNAME if you need authentication
mtn: connecting to mtn://127.0.0.1:8691/prjek?net.prjek.{fnord,foobar}
mtn: Received warning from usher: No server named 
'prjek?net.prjek.{fnord,foobar}'
mtn: error: I/O failure while talking to peer 
mtn://127.0.0.1:8691/prjek?net.prjek.{fnord,foobar}, disconnecting
mtn: setting default server to mtn://127.0.0.1:8691/example?org.example
mtn: setting default branch include pattern to 'org.example'
mtn: setting default branch exclude pattern to ''
mtn: doing anonymous pull; use -kKEYNAME if you need authentication
mtn: connecting to mtn://127.0.0.1:8691/example?org.example
mtn: Received warning from usher: No server named 'example?org.example'
mtn: error: I/O failure while talking to peer 
mtn://127.0.0.1:8691/exampl

Re: [Monotone-devel] usher 0.99 release (name-based virtual hosting for monotone)

[Hendrik Boom]

On Tue, Nov 09, 2010 at 08:50:26PM -0600, Timothy Brownawell wrote:
> On 11/08/2010 01:49 PM, Hendrik Boom wrote:
>> On Fri, Nov 05, 2010 at 11:46:03PM -0500, Timothy Brownawell wrote:
>>> There is an actual release of usher available now. It's tagged as
>>> usher-0.99 available from
>>> mtn://monotone.ca/contrib?net.venge.monotone.usher
>>> and there is a tarball available at
>>> http://mtn-host.prjek.net/projects/webhost/files/usher-0.99.tar.gz
>>
>> I did the ./configure, and make, and then I did make test
>> I got a lot of stuff that looked like errors, but I suspect that the
>> complete test environment wasn't available on my system.  I don't, to my
>> knowledge, have a server mtn://127.0.0.1:8691/prjek-s?net.prjek.separate
>> or is that something the test scripts should have set up?
>>
>>> . It works on at least Debian and FreeBSD.
>>
>> Using a Debian stable running on a 64-bit AMD64.
>
> It wants socat installed, and it doesn't properly handle when monotone  
> sends the query string as part of the server name (it shouldn't do that  
> and 0.99 doesn't, but I think 0.48 does). It really should handle that,  
> and test against multiple monotone versions if available...

If I understand you correctly, this is just a problem with the test 
suite, and not with usher itself?  So I can just proceed to use usher 
without bothering with the tests?

Of course, to be sure, I should install socat and repeat.  And if I 
still have trouble, try with mtn 0.99?

Is sending the query string as part of the server name a problem for 
usher, or just for the test suite?

-- hendrik

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

Re: [Monotone-devel] 'SelfHostingInfo' on mtn wiki

[Hendrik Boom]

On Sun, Nov 07, 2010 at 05:12:27PM +0100, Richard Levitte wrote:
> In message <4cd6c3c1.4020...@unchartedbackwaters.co.uk> on Sun, 07 Nov 2010 
> 15:20:33 +, Francis Russell  said:
> 
> francis> Richard Levitte wrote:
> francis> 
> francis> > I have already made changes to this page and committed them...  
> francis> 
> francis> It might be helpful to also have some instructions for <=0.48 users
> francis> (even just to point them to old.monotone.ca). Those versions may be
> francis> alive for a while.
> 
> Done.
> 
> I've tested the command that I gave for <=0.48 with 0.48 and 0.40.

I tried using it on 0.40 (which seems to be themonotne I'm using on 
Debian lenny) in order to obtain a more up-to-date repository, and it 
didn't work.  Could it be that the wiki is still out of date even though 
you've checked in an update?   Of course I'll be downloading the 0.99 
executable to get things working instead of sticking stubbornly with lenny's
0.40, but I thought I should report this.

On http://wiki.monotone.ca/SelfHostingInfo/ it says:

$ # Command for monotone <=0.48
$ mtn --db=mtn.db clone mtn://monotone.ca/monotone "?net.venge.monotone*" \
  -b net.venge.monotone monotone

but when I try this I get:

hend...@april:~/dv/mtn$ mtn --db=mtn.db clone mtn://monotone.ca/monotone 
"?net.venge.monotone*" -b net.venge.monotone monotone
Usage: mtn [OPTION...] command [ARG...]

  --confdir  set location of configuration directory
  --db [ -d ]set name of database
  --debug print debug log to stderr while running
  --dump file to dump debugging log to, on failure
  --help [ -h ]   display help message
  --ignore-suspend-certs  do not ignore revisions marked as suspended
  --key [ -k ]   set key for signatures
  --keydir   set location of key store
  --log  file to write the log to
  --no-default-confdirforbid use of the default confdir
  --norc  do not load ~/.monotone/monotonerc or _MTN/monotonerc
  lua files
  --nostd do not load standard lua hooks
  --quiet suppress verbose, informational and progress messages
  --rcfile   load extra rc file
  --reallyquiet   suppress warning, verbose, informational and progress
  messages
  --root limit search for workspace to specified root
  --ssh-sign controls use of ssh-agent.  valid arguments are: 'yes'
  to use ssh-agent to make signatures if possible, 'no'
  to force use of monotone's internal code, 'only' to
  force use of ssh-agent, 'check' to sign with both and
  compare
  --ticker   set ticker style (count|dot|none)
  --version   print version number, then exit
  --xargs [ -@ ] insert command line arguments taken from the given
  file

Options specific to 'mtn clone':

  --branch [ -b ] select branch cert for operation
  --revision [ -r ]   select revision id for operation

Syntax specific to 'mtn clone':

  clone ADDRESS[:PORTNUMBER] [DIRECTORY]

Description for 'mtn clone':

  Checks out a revision from a remote database into a directory.

  If a revision is given, that's the one that will be checked out.  Otherwise,
  it will be the head of the branch supplied.  If no directory is given, the
  branch name will be used as directory

hend...@april:~/dv/mtn$ exit


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

[Monotone-devel] compiling on lennty from downloaded tarball

[Hendrik Boom]

Well, I downloaded the tarball, untarred it, and ./configure failed.  It 
turned out that when I installed to list of packages specified for 
Debian and Ubunto there was no libbotan-dev.  Instead, though there were 
libbotan1.6-dev and a libbotan1.7-dev.

I used libbotan1.2-dev.  Everything compiled cleanly on a relatively 
up-to-date AMD64 Debian lenny.  Then mtn passed the tests done by make 
check.  So everything appears to be good on this platform, except for 
the package name in the INSTALL file.

-- hendrik


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

Re: [Monotone-devel] compiling on lennty from downloaded tarball

[Hendrik Boom]

On Tue, Nov 16, 2010 at 01:43:39PM -0500, Hendrik Boom wrote:
> Well, I downloaded the tarball, untarred it, and ./configure failed.  It 
> turned out that when I installed to list of packages specified for 
> Debian and Ubunto there was no libbotan-dev.  Instead, though there were 
> libbotan1.6-dev and a libbotan1.7-dev.

But I forgot to mention this was the 0.99.1 tarball.

> 
> I used libbotan1.2-dev.  Everything compiled cleanly on a relatively 
> up-to-date AMD64 Debian lenny.  Then mtn passed the tests done by make 
> check.  So everything appears to be good on this platform, except for 
> the package name in the INSTALL file.
> 
> -- hendrik
> 
> 
> ___
> Monotone-devel mailing list
> Monotone-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/monotone-devel

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

Re: [Monotone-devel] usher 0.99 release (name-based virtual hosting for monotone)

[Hendrik Boom]

On Fri, Nov 05, 2010 at 11:46:03PM -0500, Timothy Brownawell wrote:
> There is an actual release of usher available now. It's tagged as
> usher-0.99 available from
>mtn://monotone.ca/contrib?net.venge.monotone.usher
> and there is a tarball available at
>http://mtn-host.prjek.net/projects/webhost/files/usher-0.99.tar.gz

I started over after compiling and installing mtn 0.99.1.
I configured, compile, and ran the check and it passed, ending up 
by saying:

Test finished.
PASS test1
PASS: test/run-tests.sh
=
1 test passed
=
make[1]: Leaving directory `/farhome/hendrik/dv/usher/usher-0.99'

-- hendrik

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

Re: [Monotone-devel] usher 0.99 release (name-based virtual hosting for monotone)

[Hendrik Boom]

On Mon, Nov 08, 2010 at 02:04:46PM -0500, Hendrik Boom wrote:
> 
> I guess now comes the inevitable flood of stupid questions as i try to 
> make sense of the documentation.

More stupid question.

(1) The listen addr in the sample script is 0.0.0.0:4691.

   The 4691 is the usual monotone port number.

   But I'm not familiar with IP to know what the 0.0.0.0 means.  Does 
   it mean it listens on all interfaces on the machine?

(2) Is there a comment convention for the usher config file?

-- hendrik

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

Re: [Monotone-devel] How far back to we want to maintain?

[Hendrik Boom]

On Sat, Nov 20, 2010 at 11:22:41AM +0100, Richard Levitte wrote:
> Hi,
> 
> I just noticed Timothy's backports of the sqlite-blob-null fix to
> versions branches for 0.44 and 0.46, and that had me wonder how far
> back we want to maintain monotone.  I'm not saying Timothy did a bad
> thing here, but it does raise the question, doesn't it?

At present, Debian stable is still on 0.40.  This will change in a few 
months, but Debian will still be maintaining it as oldstable for at 
least a year after that.

I don't know how many of our users are still using Debian stable for 
servers.  I am, but I'm also compiling my own more up-to-date mtn.

-- hendrik

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

Re: Release rules Was: Re: [Monotone-devel] conflicts store vs show_conflicts

[Hendrik Boom]

On Mon, Nov 22, 2010 at 08:17:38AM -0600, Timothy Brownawell wrote:
>
> So I think basically rpm requires X.Y.Z even/odd scheme in order to  
> distinguish release/dev. Which is annoying.

The colon classification system had a scheme where some symbols would 
collate before end-od-string.  They used lower-case letters for this, so 
75a came before 75
75 came before 75A
Are there any such characters for use with the well-known package 
managers?

-- hendrik

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

Re: Release rules Was: Re: [Monotone-devel] conflicts store vs show_conflicts

[Hendrik Boom]

On Mon, Nov 22, 2010 at 10:18:47AM -0500, Hendrik Boom wrote:
> On Mon, Nov 22, 2010 at 08:17:38AM -0600, Timothy Brownawell wrote:
> >
> > So I think basically rpm requires X.Y.Z even/odd scheme in order to  
> > distinguish release/dev. Which is annoying.
> 
> The colon classification system had a scheme where some symbols would 
> collate before end-od-string.  They used lower-case letters for this, so 
> 75a came before 75
> 75 came before 75A
> Are there any such characters for use with the well-known package 
> managers?

Yes, there is one -- the tilde.  Here's a part of the DEbian 
specification for how upstream version numbers (i.e., ours) are to be 
sorted.I quote from 
http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version

===

First the initial part of each string consisting entirely of non-digit 
characters is determined. These two parts (one of which may be empty) 
are compared lexically. If a difference is found it is returned. The 
lexical comparison is a comparison of ASCII values modified so that all 
the letters sort earlier than all the non-letters and so that a tilde 
sorts before anything, even the end of a part. For example, the 
following parts are in sorted order from earliest to latest: ~~, ~~a, ~, 
the empty part, a.[

Then the initial part of the remainder of each string which consists 
entirely of digit characters is determined. The numerical values of 
these two parts are compared, and any difference found is returned as 
the result of the comparison. For these purposes an empty string (which 
can only occur at the end of one or both version strings being compared) 
counts as zero.

These two steps (comparing and removing initial non-digit strings and 
initial digit strings) are repeated until a difference is found or both 
strings are exhausted. 

===

This if we add ~dev7 to version number 1.1, we'll get version 1.1~dev7, 
which will sort before version 1.1

This sounds like the numbering system we're looking for.

Of course, this isn't the *entire* comparison alrorithm. There's also 
an epoch and a Debian-specific attachment to the verison number.  Check 
the link above for further details.

-- hendrik

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

Re: Release rules Was: Re: [Monotone-devel] conflicts store vs show_conflicts

[Hendrik Boom]

On Mon, Nov 22, 2010 at 05:28:23PM -0600, Timothy Brownawell wrote:
> On 11/22/2010 09:43 AM, Hendrik Boom wrote:
>> This if we add ~dev7 to version number 1.1, we'll get version 1.1~dev7,
>> which will sort before version 1.1
>>
>> This sounds like the numbering system we're looking for.
>>
>> Of course, this isn't the *entire* comparison alrorithm. There's also
>> an epoch and a Debian-specific attachment to the verison number.  Check
>> the link above for further details.
>
> Yep, that would be ideal except it looks like rpm-based distros don't  
> support it.

Maybe we should log a bug against rpm itself.

-- hendrik

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

Re: Release rules Was: Re: [Monotone-devel] conflicts store vs show_conflicts

[Hendrik Boom]

On Mon, Nov 22, 2010 at 11:46:49PM -0500, Hendrik Boom wrote:
> On Mon, Nov 22, 2010 at 05:28:23PM -0600, Timothy Brownawell wrote:
> > On 11/22/2010 09:43 AM, Hendrik Boom wrote:
> >> This if we add ~dev7 to version number 1.1, we'll get version 1.1~dev7,
> >> which will sort before version 1.1
> >>
> >> This sounds like the numbering system we're looking for.
> >>
> >> Of course, this isn't the *entire* comparison alrorithm. There's also
> >> an epoch and a Debian-specific attachment to the verison number.  Check
> >> the link above for further details.
> >
> > Yep, that would be ideal except it looks like rpm-based distros don't  
> > support it.
> 
> Maybe we should log a bug against rpm itself.

Maybe we should first find out what the actual specifications are for 
version numbers in rpm.

-- hendrik

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

Re: [Monotone-devel] Recruiting and Planning

[Hendrik Boom]

On Fri, Nov 26, 2010 at 01:53:24AM +0100, Thomas Keller wrote:
> 
> Hi all!
> 
> I have a bit the impression that bigger parts of our community are in
> suspend mode (beside a few usual suspects) and because I don't want to
> see you all go hibernating soon, here is a deal:
> 
> 1) we need more people, especially somebody for design (site, ci,
> documents, etc.) and documentation (a technical writer with proper tool
> knowledge would be awesome) - so if you don't have the time / mood to do
> something yourself for monotone, you might at least know somebody for
> these tasks and you could do us a favour by asking them if they have
> some spare time and are interesting in joining our little team. bribe
> them with cookies, beer, cups or t-shirts as needed, or simply with the
> good thing they'll do with it.
> 
> 2) the wiki is in a horrid state and the manual could need some cleanups
> as well (e.g. moving stuff like the long discussions at the end and
> other smaller things). as the response on my "Road to 1.0" mail was
> rather low and we all don't like to do these things on our own I am for
> holding another mini sprint, i.e. one full or two half days, depending
> on the feedback, this time called "docathon" because of the emphasis on
> documentation. we should roughly team up beforehand though so that we do
> not end with an inconistent result at the end.

I'd like to help with the documentation.  If it's a matter of 
reorganising what's already there, cleaning up awkward phrasing, 
making things less obscure than the are already (provided I know 
what needs to be said) I can certianly help.

If it's a metter of providing information that's not there at 
the moment, I can't say I can help; most of my knowledge of 
monotone comes from the documentation, and what's not there is 
not there.

But I can draft best guesses that might be of use to beginners, 
subject to complaints by those who really know the stuff.

I am not available in November, though.  I'll probably have to 
register in some way with the wiki or the central monotone 
repository, though.  Where and how do I do that?  I gather the 
details have changed recently.

-- hendrik

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

Re: [Monotone-devel] branch management

[Hendrik Boom]

On Tue, Dec 07, 2010 at 05:47:23PM +0100, Thomas Keller wrote:
> 
> Hi all!
> 
> I appreciate that people take care about older releases and open
> branches for them to backport fixes, but I think two things are easily
> forgotten and should be considered by anybody touching these:
> 
> 1) If a new branch is created off trunk for a patch release and you make
> your first commit, its your responsibility to change the version number
> to "0..dev" for mtn < 1.0. If we follow the new
> proposed version numbering scheme, this would mean
> ...90 for new patch versions, which eventually gets
> .., but I'm open for other - less ugly -
> suggestions here.

Do we run the risk of several patch branches being extant simultaneously 
and ending up with the same 0.minor.patch+1 number?  Presumably this 
would have to be changed when finally merging the patch.

> 
> 2) Likewise when the first change is made, a corresponding NEWS entry
> should be written, so we don't start to digg though the commit log of
> the particular branch for a patch release, but have something to build upon.
> 
> 3) Usually one would fix a bug in a release branch and merge it into
> trunk, but this merge could bring over unwanted changes (like changes in
> NEWS, configure.ac and maybe others), so the best is probably to use
> pluck as most of you already did.
> 
> 
> Now to the question which branches we really want to take care of.
> 
> Since 0.48 is quite around I think it makes sense to support this a
> little longer - at least until Debian moves to a newer version - and
> backport important stuff as needed.

That'll be a long time, sonce 0.48 is currentl;y Debian testing, and 
will be around as stable for a very long time.  Unless we can get 1.0 
into testing before the release.  Which I consider unlikely.

> Richard recently added the updated French translation to 0.48 (probably
> because the original author created a patch against this version) and
> this was already kind of a corner case, because I think we should really
> try to keep calm in this area and avoid lots of work backporting
> non-crucial things to older branches.
> The translation update of course did not break anything for us, but I
> don't know for example if Debian policies allow i18n updates at all in
> the lifetime of a package and if this work is actually seen for 0.48
> users. (I do think its seen otherwise the original author wouldn't have
> send the patch probably, but I don't know the rules enough).
> 
> Other versions beside 0.48 are currently not quite on my agenda beside
> the most recent version / branch 0.99, so again, unless people start
> screaming very loud at us we should try and keep the work and ourselves
> calm.

I think 0.40 is in Debian stable right now, but that should be gone in a 
few months.(or at least become oldstable).

> 
> Questions / comments / clarifications? If you're ok with the things
> written above, I could move them into the wiki and / or document them in
> notes/release-checklist.txt.
> 
> 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
> 
> 



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


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

Re: [Monotone-devel] Preparing for docathon

[Hendrik Boom]

On Sat, Dec 18, 2010 at 05:03:24PM +0100, Richard Levitte wrote:
> Hi,
> 
> A few words about the upcoming docathon.
> 
> Thomas Keller is the initiator and thereby has a natural leading
> role.  However, he might not be part of part of the effort tomorrow
> evening and has therefore asked me to be a stand in.
> 
> I will be present on IRC most of the time (huge exception for early
> afternoon tomorrow), and especially tomorrow (Sunday) from 16ish to
> midnight UTC.
> 
> The thoughts below are what we have come up with for now.  If you have
> a pet doc thing you'd like to see included, please tell us!
> 
> 
> 
> The wiki
> 
> 
> I've done some preparations for this weekend's docathon, at least with
> the wiki.  All pages have been tagged 'needs-reviewing', and those are
> the first that one should look at.  The first effort is to do a quick
> job; if you can do a minor fix on a page, do it, but otherwise, the
> job is initially meant to categorise the pages.  This is done by
> changing the tag 'needs-reviwing' to one of the following:
> 
>   * 'reviewed-ok' would mean it was ok, or minor fixes were made so it
> is now ok.
>   * 'reviewed-delete' would require confirmation from a second
> reviewer; if they agree, they could simply delete the file.
>   * 'reviewed-needs-work' means that some work has been done, but it
> needs more than we want to handle at the moment. Hopefully, such
> pages will be rare, or at least temporary.
> 
> 
> The wiki page http://wiki.monotone.ca/Review/2010/ contains the lists
> of pages marked 'needs-reviewing', 'reviewed-needs-work',
> 'reviewed-delete' and 'reviewed-ok', and gets updated everytime one of
> those tags are changed (just make sure to reload it).  it should
> therefore be pretty easy to just pick a page to work with.
> 
> The next step, which can happen in parallell, is to take on the pages
> that are tagged 'reviewed-needs-work' and work with it.  If you don't
> know what to do with it or need ideas/inspiration, please just ask on
> IRC.  One most notable page that really needs work is the front page
> (http://wiki.monotone.ca).  That one's worth talking about!
> 
> 
> ==
> The manual
> ==
> 
> Various work is needed here.
> 
> Someone could check that all commands are present in the manual
> (remember, 0.99 has quiet a number of changes and additions) so
> nothing is forgotten.  Making sure we have a complete reference
> section would be awesome!
> 
> Some commands in the command section might need more examples.  If you
> have something you wish for, please say so, and if you're inclined,
> please offer a patch or commit a change.  This doesn't have to be big,
> small examples are usually good!
> 
> Some sections of the manual could really be moved to the wiki.  The
> most notable example is the mark-merge discussion.
> 
> 
> ==
> Source
> ==
> 
> INSTALL would need to be split by platform.
> README would need a bit more text, a short presentation of monotone,
> so people starting there can get to know what they just downloaded!
> 
> 
> =
> Other
> =
> 
> Someone could write up 5 minute intros to monotone.  "mtn for git
> users", "mtn for svn users", and so on.  Maybe this belongs in the
> manual, maybe on the wiki, maybe on monotone's main web page
> (http://monotone.ca).  It doesn't really matter where we put them
> tight now, the most important is that they get written and committed
> somewhere!

The reverse would also be useful -- svn for mtn users, and the like.  I 
often have to use or contribute to a project that uses svn or git, 
though my own inclination is to use mtn.

Knowing how to coordinate mtn and other use would be especially sweet -- 
maintinaing my own development on such a project in mtn (on multiple 
machines) and, when the time comes, issue the commands to check them 
in or our of svn or git, and sync with headquarters.

Or just maintianing an svn vendor branch whilc I use mtn.

Doing all this is probably more complex than just indicating what scn 
and git commands correspond to mtn ones, though.

-- hendrik

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

Re: [Monotone-devel] Preparing for docathon

[Hendrik Boom]

On Sat, Dec 18, 2010 at 05:03:24PM +0100, Richard Levitte wrote:
> 
> ==
> The manual
> ==
> 
> Various work is needed here.
> 
> Someone could check that all commands are present in the manual
> (remember, 0.99 has quiet a number of changes and additions) so
> nothing is forgotten.  Making sure we have a complete reference
> section would be awesome!

It would also be useful if the command desriptions in the manual 
contained *all* the possible operands and options, including the ones 
normally obtained from context.

-- hendrik

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

[Monotone-devel] minor documentation bug in 0.99.1

[Hendrik Boom]

The INSTALL file says, for Debian

 install the following packages:
 autoconf automake gettext g++ libboost-dev libz-dev
 libbotan-dev libsqlite3-dev libpcre3-dev liblua5.1-0-dev
 libidn11-dev libgmp3-dev libbz2-dev texinfo

   (On etch, you may need to use libbotan1.7 from lenny.)

But on lenny, you also have to use libbotan1.7 from lenny; there's no 
libbotan package.

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

Re: [Monotone-devel] Not so minor problem in 0.99.1

[Hendrik Boom]

On Mon, Jan 03, 2011 at 10:44:27AM -0500, Hendrik Boom wrote:
> The INSTALL file says, for Debian
> 
>  install the following packages:
>  autoconf automake gettext g++ libboost-dev libz-dev
>  libbotan-dev libsqlite3-dev libpcre3-dev liblua5.1-0-dev
>  libidn11-dev libgmp3-dev libbz2-dev texinfo
> 
>(On etch, you may need to use libbotan1.7 from lenny.)
> 
> But on lenny, you also have to use libbotan1.7 from lenny; there's no 
> libbotan package.

Unfortunately, even with libbotan1.7 and libbotan1.7-dev installed, when 
running .'configure I still get

checking for botan... no
botan.pc not found
checking for botan using botan-config... yes
checking whether botan is usable... no
configure: *** botan_CFLAGS=
configure: *** botan_LIBS=-L/usr/lib -lm -lbz2 -lcrypto -lgmp -lpthread 
-lrt -lz -lbotan
configure: error: in `/farhome/hendrik/dv/monotone/monotone-0.99.1':
configure: error: Must be able to compile and link programs against 
botan.
See `config.log' for more details


Checking config.log:

configure:4749: checking for botan
configure:4757: $PKG_CONFIG --exists --print-errors "botan$_verreq"
Package botan was not found in the pkg-config search path.
Perhaps you should add the directory containing `botan.pc'
to the PKG_CONFIG_PATH environment variable
No package 'botan' found
configure:4760: $? = 1
configure:4775: $PKG_CONFIG --exists --print-errors "botan$_verreq"
Package botan was not found in the pkg-config search path.
Perhaps you should add the directory containing `botan.pc'
to the PKG_CONFIG_PATH environment variable
No package 'botan' found
configure:4778: $? = 1
No package 'botan' found
configure:4806: result: no
configure:4808: result: botan.pc not found
configure: candidate .pc files are:
configure: candidate -config programs are:
| /usr/bin/botan-config
configure:4946: checking for botan using botan-config
configure:4953: result: yes
configure:4974: checking whether botan is usable
configure:4998: g++ -o conftest -g -O2 -Wall -W -Wno-unused
conftest.cpp -lz  -L/usr/lib -lm -lbz2 -lcrypto -lgmp -lpthread -lrt -lz 
-lbotan >&5
/usr/bin/ld: cannot find -lcrypto
collect2: ld returned 1 exit status
configure:4998: $? = 1
configure: failed program was:
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "monotone"
| #define PACKAGE_TARNAME "monotone"
| #define PACKAGE_VERSION "0.99.1"
| #define PACKAGE_STRING "monotone 0.99.1"
| #define PACKAGE_BUGREPORT "monotone-devel@nongnu.org"
| #define PACKAGE_URL ""
| #define PACKAGE "monotone"
| #define VERSION "0.99.1"
| #define os_err_t int
| #define ENABLE_NLS 1
| /* end confdefs.h.  */
| #include 
|  #if BOTAN_VERSION_CODE < BOTAN_VERSION_CODE_FOR(1,6,3)
|  #error too old
|  #endif
|  #if BOTAN_VERSION_CODE == BOTAN_VERSION_CODE_FOR(1,7,14)
|  #error version 1.7.14 is not usable for monotone
|  #endif
| int
| main ()
| {
| Botan::LibraryInitializer li;
|   ;
|   return 0;
| }
| 
configure:5007: result: no
configure:5010: *** botan_CFLAGS=
configure:5012: *** botan_LIBS=-L/usr/lib -lm -lbz2 -lcrypto -lgmp 
-lpthread -lrt -lz -lbotan
configure:5014: error: in 
`/farhome/hendrik/dv/monotone/monotone-0.99.1':
configure:5016: error: Must be able to compile and link programs against 
botan.
See `config.log' for more details



Searching the Debian package data base 
http://www.debian.org/distrib/packages
fails to find any packages in stable containing a file named botan.pc

I guess I'll try to find the precompiles executable.

-- hendrik

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

Re: [Monotone-devel] Not so minor problem in 0.99.1

[Hendrik Boom]

On Mon, Jan 03, 2011 at 05:55:27PM +0100, Richard Levitte wrote:
> In message <20110103155639.gc27...@topoi.pooq.com> on Mon, 3 Jan 2011 
> 10:56:40 -0500, Hendrik Boom  said:
> 
> hendrik> Unfortunately, even with libbotan1.7 and libbotan1.7-dev installed, 
> when 
> hendrik> running .'configure I still get
> hendrik> 
> hendrik> checking for botan... no
> hendrik> botan.pc not found
> hendrik> checking for botan using botan-config... yes
> hendrik> checking whether botan is usable... no
> hendrik> configure: *** botan_CFLAGS=
> hendrik> configure: *** botan_LIBS=-L/usr/lib -lm -lbz2 -lcrypto -lgmp 
> -lpthread 
> hendrik> -lrt -lz -lbotan
> hendrik> configure: error: in `/farhome/hendrik/dv/monotone/monotone-0.99.1':
> hendrik> configure: error: Must be able to compile and link programs against 
> hendrik> botan.
> hendrik> See `config.log' for more details
> hendrik> 
> [...]
> hendrik> 
> hendrik> Searching the Debian package data base 
> hendrik> http://www.debian.org/distrib/packages
> hendrik> fails to find any packages in stable containing a file named botan.pc
> 
> That's not the issue.  libbotan1.7 contains the program botan-config,
> which can be used as well, and if you look again, it was used and
> correctly identified botan for you.
> 
> However, a few lines further down, there's this:
> 
> hendrik> conftest.cpp -lz  -L/usr/lib -lm -lbz2 -lcrypto -lgmp -lpthread -lrt 
> -lz 
> hendrik> -lbotan >&5
> hendrik> /usr/bin/ld: cannot find -lcrypto
> 
> That's where the problem is...
> 
> Quite honestly, though, I'm a bit surprised this should happen at
> all.  libbotan1.7 depends on libssl0.9.8, which delivers libcrypto...
> So the question is, what's up with that?

libssl10.9.8 provides libcrypto in

/usr/lib/i486/libcrypto.so.0.9.8
/usr/lib/i586/libcrypto.so.0.9.8
/usr/lib/i686/cmov/libcrypto.so.0.9.8
/usr/lib/libcrypto.so.0.9.8

and all of these are present on my system.

hend...@lovesong:~/dv$ ls -l /usr/lib/i486/libcrypto.so.0.9.8 
/usr/lib/i586/libcrypto.so.0.9.8 /usr/lib/i686/cmov/libcrypto.so.0.9.8 
/usr/lib/libcrypto.so.0.9.8
-rw-r--r-- 1 root root 1334692 2010-11-16 13:24 /usr/lib/i486/libcrypto.so.0.9.8
-rw-r--r-- 1 root root 1293732 2010-11-16 13:24 /usr/lib/i586/libcrypto.so.0.9.8
-rw-r--r-- 1 root root 1375588 2010-11-16 13:24 
/usr/lib/i686/cmov/libcrypto.so.0.9.8
-rw-r--r-- 1 root root 1416548 2010-11-16 13:24 /usr/lib/libcrypto.so.0.9.8
hend...@lovesong:~/dv$ 

I agree.  The question is, what's up with that?

-- hendrik

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

Re: [Monotone-devel] Not so minor problem in 0.99.1

[Hendrik Boom]

On Mon, Jan 03, 2011 at 10:28:56AM -0800, Zack Weinberg wrote:
> On Mon, Jan 3, 2011 at 9:26 AM, Hendrik Boom  wrote:
> >> hendrik> conftest.cpp -lz  -L/usr/lib -lm -lbz2 -lcrypto -lgmp -lpthread 
> >> -lrt -lz
> >> hendrik> -lbotan >&5
> >> hendrik> /usr/bin/ld: cannot find -lcrypto
> >>
> >> That's where the problem is...
> >>
> >> Quite honestly, though, I'm a bit surprised this should happen at
> >> all.  libbotan1.7 depends on libssl0.9.8, which delivers libcrypto...
> >> So the question is, what's up with that?
> >
> > libssl10.9.8 provides libcrypto in
> >
> > /usr/lib/i486/libcrypto.so.0.9.8
> > /usr/lib/i586/libcrypto.so.0.9.8
> > /usr/lib/i686/cmov/libcrypto.so.0.9.8
> > /usr/lib/libcrypto.so.0.9.8
> >
> > and all of these are present on my system.
> 
> Is libssl-dev installed?  Does the botan-dev package (whatever it's
> actually named) depend on libssl-dev, as it seems it needs to?

OK.  I'm firing up aptitude interactive and taking a look.

libbotan1.7-dev is intalled, version 1.7.8-3

It depends on libbotan1.7, which is also installed, version 1.7.8-3

libbotan1.7 depends on a number of things, including libssl0.9.8

libssl0.9.8 is installed, version 0.9.8g-15+lenny9

But I find no dependency on libssl-dev.

-- hendrik

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

Re: [Monotone-devel] Not so minor problem in 0.99.1

[Hendrik Boom]

On Mon, Jan 03, 2011 at 10:28:56AM -0800, Zack Weinberg wrote:
> On Mon, Jan 3, 2011 at 9:26 AM, Hendrik Boom  wrote:
> >> hendrik> conftest.cpp -lz  -L/usr/lib -lm -lbz2 -lcrypto -lgmp -lpthread 
> >> -lrt -lz
> >> hendrik> -lbotan >&5
> >> hendrik> /usr/bin/ld: cannot find -lcrypto
> >>
> >> That's where the problem is...
> >>
> >> Quite honestly, though, I'm a bit surprised this should happen at
> >> all.  libbotan1.7 depends on libssl0.9.8, which delivers libcrypto...
> >> So the question is, what's up with that?
> >
> > libssl10.9.8 provides libcrypto in
> >
> > /usr/lib/i486/libcrypto.so.0.9.8
> > /usr/lib/i586/libcrypto.so.0.9.8
> > /usr/lib/i686/cmov/libcrypto.so.0.9.8
> > /usr/lib/libcrypto.so.0.9.8
> >
> > and all of these are present on my system.
> 
> Is libssl-dev installed?  Does the botan-dev package (whatever it's
> actually named) depend on libssl-dev, as it seems it needs to?

libssl-dev is not installed.  Nor is in mentioned in 
monotone-0.99.1/INSTALL as something that should be installed.

-- hendrik

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

Re: [Monotone-devel] mingw-instructions

[Hendrik Boom]

On Sun, Jan 09, 2011 at 05:16:23AM -0500, Stephen Leake wrote:
> Timothy Brownawell  writes:
> 
> > On 01/08/2011 06:19 PM, Stephen Leake wrote:
> >
> >> Correct. But it would be nice to document how the executables on our
> >> download page are built. In fact, that's a requirement of the GPL 3
> >> license
> >
> > Some of our downloads like the Windows installer bundle the libraries we
> > use. So for any copyleft libraries, we really ought to actually host the
> > source for the version used.
> 
> I believe the actual requirements of GPL 2
> (http://www.gnu.org/licenses/gpl-2.0.txt, item 3) are that the source be
> available, and that we tell people how to get it. So I think the current
> INSTALL_windows_native.txt is ok in that regard.

I seem to remember something in the old GPL saying that the instructions 
for getting the source had to be valid for two years.  And some 
discussion from the FSF saying that thoe source for the *same version* 
be available.  So if after 18 months someone came looking for the source 
code for the library, he has to be able to get at
 18-month-old source code.  Not that the guy might not prefer current 
source code, of course, but it's the code that produced the binary he 
got that the licence guarantees.

It seemed logical to me, but probably awkward in practice, unless you 
ship the source code with the binary.

-- hendrik

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

Re: [Monotone-devel] mingw-instructions

[Hendrik Boom]

On Sun, Jan 09, 2011 at 03:05:30PM -0500, Stephen Leake wrote:
> 
> We don't have enough manpower to do everything right.
> 

Nobody does.

-- hendrik

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

Re: [Monotone-devel] mingw-instructions

[Hendrik Boom]

On Mon, Jan 10, 2011 at 05:02:13AM -0500, Stephen Leake wrote:
> Timothy Brownawell  writes:
> >
> > Mostly I'm annoyed at the change from straight copyleft to forbidding it
> > from being used as part of things with certain properties. Not that the
> > particular properties they picked are likely to be relevant for a
> > developer tool, so maybe it doesn't really matter that much...
> >
> >> I don't think the process of upgrading requires getting approval from
> >> all current authors, because our license statements say "GPL 2 or greater".
> >> But I'm not a lawyer, so maybe that doesn't mean we get to change it to
> >> "GPL 3 or greater".
> >
> > AIUI changing the license statements on existing code requires
> > agreement, but you could also get much the same effect by just changing
> > the statements for new code... 
> 
> Good point.
> 
> > which seems to already be the case, see {unix,win32}/parse_date.cc .
> 
> That was me. We should have a project-wide agreement on using GPL 3 for
> new code (or not).

Using "GPL 3 or later" instead of "GPL 2 or later" tightens 
restrictions.  A user can already do everything GPL 3 permits because of 
the "or later" clause.  But the user will be restricted from things that 
GPL 2 permits but GPL 3 forbids.  What are those things?  And are any of 
them important enough to the monotone developers that it's important to 
restrict the users, who may have applications and needs we cannot dream 
of?

-- hendrik

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

Re: [Monotone-devel] Not so minor problem in 0.99.1

[Hendrik Boom]

So what's the final decision on this problem?  A change in the list of 
other packages that have to be installed first?  A change in the 
dependencies in Debian's packages?  (in which case I hope the necessary 
bug report is on its way to Dexbian)  A change in the -lcrypto link 
option?

Let me know when it's time to try another install-from-source test on 
this machine, starting from the same system configuration.

-- hendrik

On Mon, Jan 03, 2011 at 03:43:32PM -0500, Hendrik Boom wrote:
> On Mon, Jan 03, 2011 at 10:28:56AM -0800, Zack Weinberg wrote:
> > On Mon, Jan 3, 2011 at 9:26 AM, Hendrik Boom  wrote:
> > >> hendrik> conftest.cpp -lz  -L/usr/lib -lm -lbz2 -lcrypto -lgmp -lpthread 
> > >> -lrt -lz
> > >> hendrik> -lbotan >&5
> > >> hendrik> /usr/bin/ld: cannot find -lcrypto
> > >>
> > >> That's where the problem is...
> > >>
> > >> Quite honestly, though, I'm a bit surprised this should happen at
> > >> all.  libbotan1.7 depends on libssl0.9.8, which delivers libcrypto...
> > >> So the question is, what's up with that?
> > >
> > > libssl10.9.8 provides libcrypto in
> > >
> > > /usr/lib/i486/libcrypto.so.0.9.8
> > > /usr/lib/i586/libcrypto.so.0.9.8
> > > /usr/lib/i686/cmov/libcrypto.so.0.9.8
> > > /usr/lib/libcrypto.so.0.9.8
> > >
> > > and all of these are present on my system.
> > 
> > Is libssl-dev installed?  Does the botan-dev package (whatever it's
> > actually named) depend on libssl-dev, as it seems it needs to?
> 
> libssl-dev is not installed.  Nor is in mentioned in 
> monotone-0.99.1/INSTALL as something that should be installed.
> 
> -- hendrik
> 
> ___
> Monotone-devel mailing list
> Monotone-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/monotone-devel

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

Re: [Monotone-devel] usher 0.99 release (name-based virtual hosting for monotone)

[Hendrik Boom]

On Sat, Nov 20, 2010 at 02:22:37AM +0100, Richard Levitte wrote:
> In message <20101119201102.ga25...@topoi.pooq.com> on Fri, 19 Nov 2010 
> 15:11:02 -0500, Hendrik Boom  said:
> 
> hendrik> (2) Is there a comment convention for the usher config file?
> 
>   comment "This is a lengthy comment"

The comment has to be in quotes?
Are newlines allowed?
Should this be documented in 
https://code.monotone.ca/p/contrib/page/UsherDocumentation/
?

-- hendrik

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

[Monotone-devel] usher comments

[Hendrik Boom]

On Mon, Jan 31, 2011 at 09:09:33AM +0100, Richard Levitte wrote:
> In message <20110131075604.ga14...@topoi.pooq.com> on Mon, 31 Jan 2011 
> 02:56:04 -0500, Hendrik Boom  said:
> 
> hendrik> On Sat, Nov 20, 2010 at 02:22:37AM +0100, Richard Levitte wrote:
> hendrik> > In message <20101119201102.ga25...@topoi.pooq.com> on Fri, 19 Nov 
> 2010 15:11:02 -0500, Hendrik Boom  said:
> hendrik> > 
> hendrik> > hendrik> (2) Is there a comment convention for the usher config 
> file?
> hendrik> > 
> hendrik> >   comment "This is a lengthy comment"
> hendrik> 
> hendrik> The comment has to be in quotes?
> hendrik> Are newlines allowed?
> hendrik> Should this be documented in 
> hendrik> https://code.monotone.ca/p/contrib/page/UsherDocumentation/
> hendrik> ?
> 
> Quoted from that page:
> 
>   The configuration file for usher approximately follows monotone's 
> "basic_io" format
> 
> See http://monotone.thomaskeller.biz/docbuild/html/Formats.html#Formats
> for the basic_io format.
> 
> Maybe the usher documentation should point to the monotone
> documentation for this.

Actually, I've just discovered by accident that a '#' at the stat of a 
line seems to make the entire line be interpreted as a comment, quotes 
not needed.  That seems not to be mentioned in either 
 https://code.monotone.ca/p/contrib/page/UsherDocumentation/
or
 http://monotone.thomaskeller.biz/docbuild/html/Formats.html#Formats

Thanks.

-- hendrik

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

Re: [Monotone-devel] usher 0.99 release (name-based virtual hosting for monotone)

[Hendrik Boom]

On Mon, Nov 08, 2010 at 02:04:46PM -0500, Hendrik Boom wrote:
> 
> I guess now comes the inevitable flood of stupid questions as i try to 
> make sense of the documentation.
> 

Well, I have usher running, and depending on how I write the 
configuration file it reports I have one or two servers, called "write", 
the one I want to start with, and "local", the one inherited form the 
example in the documentation.

But when I try to sync with "write" from another computer, I geet 
problems:

hendrik@notlookedfor:~/write/Melinda$ mtn sync 4691://topoi.pooq.com/write
enter passphrase for key ID [hend...@notlookedfor.topoi.pooq.com] 
(ad968be7...): 
mtn: connecting to 4691://topoi.pooq.com/write
mtn: Received warning from usher: Cannot fork server.
mtn: peer 4691://topoi.pooq.com/write IO terminated connection in working state 
(error)
mtn: error: I/O failure while talking to peer 4691://topoi.pooq.com/write, 
disconnecting
hendrik@notlookedfor:~/write/Melinda$ 


Presumably something is still wrong with my configuration.
It looks as if usher does recieve the connection, identifies the
correct server ("write") in the script below, and fails to fork to start the 
server.

Hers's the configuration file (password replaced):

userpass"hendrik" "notthepasswordd"
monotone"/usr/local/bin/mtn" "-k" "hend...@topoi.pooq.com"
listenaddr  "0.0.0.0:4691"
adminaddr   "127.0.0.1:12345"
logdir  "/farhome/hendrik/monotone/usher-log/"

server  "write"
host"0.0.0.0"
pattern "com.pooq.hendrik.write*"
local   "-d" "/farhome/hendrik/monotone/write.db"

server  "local"
host"127.0.0.1"
pattern "*"
local   "-d" "/usr/local/src/managed/my.db"


Now when I try to execute the command suggested by the monotone line, 

/usr/local/bin/mtn -k hend...@topoi.pooq.com

the shell starts monotone OK, although of course monotone immediately 
complains at length that it's an invalid commant.  But from the shell, the
"fork" succeeds.

Can I get usher to tell me what the command it uses really is, 
so I can try it in isolation?  Or does it misreport a successful fork 
with an invalid monotone command as a failed fork?  Or ... (fill in 
the real explanation here, please?)

By the way, looking at the computer where usher is running, for each 
attempt to sync it gives me three requests to enter the passphrase 
for hend...@topoi.pooq.com.  But entering the passphrase there doesn't 
seem to have any effect.

By the way, the monotone running on the usher machine is 0.99.1; 
the version on the client machine is 0.48 -- the one distributed 

recently in testing as 0.48.3
 
-- hendrik


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

Re: [Monotone-devel] usher 0.99 release (name-based virtual hosting for monotone)

[Hendrik Boom]

On Wed, Feb 02, 2011 at 12:09:23AM +0100, Richard Levitte wrote:
> In message <20110201200533.ga8...@topoi.pooq.com> on Tue, 1 Feb 2011 15:05:33 
> -0500, Hendrik Boom  said:
> 
> In your configuration file, you have a logdir setting.  You might want
> to look at the log file there (write.log, I believe).

Yes.. There is oe now.  I stopped looking because for a while there 
wasn't one, but one has now showed up.  It seems to be asking me for a 
passphrase for key ID hend...@topoi.pooq.com {599fffe...}

Presumably, monotone wants a passphrase wo start up in server mode.

What's the recommended way to provide one nowadays?  The method
involving the get_passphrase hook that the tutorial says is deprecated 
because of insecurity?  It does have to be available when there's no 
user logged in on the server machine.

> hendrik> Or does it misreport a successful fork with an invalid
> hendrik> monotone command as a failed fork?  Or ... (fill in the real
> hendrik> explanation here, please?)
> 
> Well, an invalid command of some sort WOULD result in a failed fork,
> so that's definitely a plausible explanation.  Check the log in
> {logdir}.

Well, as long as the monotone process gets started, even if it 
immediately complains and exits, the fork itself has succeeded, so at 
the very least it's a misleading error message.  But at this point 
that's just a quibble.

Thanks.

-- hendrik

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

Re: [Monotone-devel] usher 0.99 release (name-based virtual hosting for monotone)

[Hendrik Boom]

On Thu, Feb 03, 2011 at 10:28:06AM +0100, Richard Levitte wrote:
> In message <20110203072618.ga27...@topoi.pooq.com> on Thu, 3 Feb 2011 
> 02:26:18 -0500, Hendrik Boom  said:
> 
> When it comes to automatic starts, such as starting a monotone server
> under usher, this is of course a problem (as it is with all mechanisms
> that require a password).  The solution still involves the
> get_passphrase hook (the deprecation is more for users than server
> maintainers), and make sure it's appropriately protected, or to use
> the expanded version contrib/get_passphrase_from_file.lua, which has
> the passphrases it need to cover in a separate file (which should be
> appropriately protected).

I don't really see a big difference between the script being protected 
and the separate file being protected.  Unless the file with the scripts 
gets to be huge with a lot of stuff that doesn't need protection, of 
course.

> 
> hendrik> > hendrik> Or does it misreport a successful fork with an invalid
> hendrik> > hendrik> monotone command as a failed fork?  Or ... (fill in the 
> real
> hendrik> > hendrik> explanation here, please?)
> hendrik> > 
> hendrik> > Well, an invalid command of some sort WOULD result in a failed 
> fork,
> hendrik> > so that's definitely a plausible explanation.  Check the log in
> hendrik> > {logdir}.
> hendrik> 
> hendrik> Well, as long as the monotone process gets started, even if it 
> hendrik> immediately complains and exits, the fork itself has succeeded, so 
> at 
> hendrik> the very least it's a misleading error message.  But at this point 
> hendrik> that's just a quibble.
> 
> There's a little bit more done to check that the monotone server has
> started correctly.  Usher waits for the server to output something and
> expects the first line to contain "beginning service".  If that
> doesn't happen, it will consider the fork a failure, hence the error
> message.  Maybe there should be a little bit more text explaining that
> one might get more answers from the appropriate log...

Maybe the message should say that the monotone server failed to 
start up correctly.  That, after all, seems to be what's being tested.
When I saw the message that the fork failed, I immediately started 
looking for ways that tthe executable file 'mtn' might not be there or 
have the wrong permissions, etc. etc.

-- hendrik

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

[Monotone-devel] still trying with usher. Now I have permissions problems.

[Hendrik Boom]

On Mon, Nov 08, 2010 at 02:04:46PM -0500, Hendrik Boom wrote:
> 
> I guess now comes the inevitable flood of stupid questions as i try to 
> make sense of the documentation.

I'm sstarting to feel stupid.

I'm getting to the monotone server via usher now.

Read 'mtn: beginning service on 127.0.0.1 : 15002
'

So that's good.
But now I'm having problems with permissions.

I get the message:
mtn: warning: protocol error while processing peer 4691://topoi.pooq.com/write: 
'received network error: denied 'ad968be7244234e8d653201ab1ddd33b53ffa04d' read 
permission for '*' excluding '' because of branch 
'com.pooq.hendrik.write.melinda''

Of course com.pooq.hendrik.write.melinda is the important branch I want to 
sync.

My .monotone/read-permissions file:

pattern "com.pooq.hendrik.write*"
allow "hend...@topoi.pooq.com"
allow "hendrik-port...@topoi.pooq.com"
allow "hend...@notlookedfor.topoi.pooq.com

pattern "com.pooq.hendrik.mtxt*"
allow "hend...@topoi.pooq.com"
allow "hend...@notlookedfor.topoi.pooq.com

pattern "com.pooq.hendrik.cash*"
allow "hend...@topoi.pooq.com"
allow "hend...@notlookedfor.topoi.pooq.com

pattern "com.pooq.hendrik.edworld*"
allow "hend...@topoi.pooq.com"
allow "hend...@notlookedfor.topoi.pooq.com


and my .monotone/write-permissions:

hend...@topoi.pooq.com
hendrik-port...@topoi.pooq.com
hend...@notlookedfor.topoi.pooq.com


Now ls .monotone/keys give me

hendrik@april:~$ ls .monotone/keys
hend...@pooq.com  hend...@topoi.pooq.com
hendrik@april:~$ 

Theres no hend...@notlookedfor.topoi.pooq.com

If I try to place a public key there I get server-side complaints that

Read 'mtn: error: Extraneous data in key store'

But when I, server side, say

mtn --db monotone/write.db read ~/pubkey

it tells me

mtn: read 1 packet

but otherwise still refuses to sync.
The pubkey, of course, is the file I generated on my other machine by running

mtn pubkey hend...@notlookedfor.topoi.pooq.com >~/april/pubkey 


-- hendrik


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

[Monotone-devel] branch patterns

[Hendrik Boom]

pattern "com.pooq.hendrik.write*"

doesn't work, but

pattern "com.pooq.hendrik.write.*"

does when I'm trying to sync branches

com.pooq.hendrik.write.melinda

and

com.pooq.hendrik.write.nano09


Why?  What are the rules for '*' and '.' in patterns?

-- hendrik


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

Re: [Monotone-devel] branch patterns

[Hendrik Boom]

On Sat, Mar 26, 2011 at 05:50:33PM -0700, J Decker wrote:
> is it behaving like regular expression? so .* is any number of any
> character?  does c.m.pooq.* work?

If that's the rule, I wouldn't expect

pattern "*"

to work, which is in the tutorial.

-- hendrik

> 
> On Sat, Mar 26, 2011 at 5:49 PM, Hendrik Boom  wrote:
> > pattern "com.pooq.hendrik.write*"
> >
> > doesn't work, but
> >
> > pattern "com.pooq.hendrik.write.*"
> >
> > does when I'm trying to sync branches
> >
> > com.pooq.hendrik.write.melinda
> >
> > and
> >
> > com.pooq.hendrik.write.nano09
> >
> >
> > Why?  What are the rules for '*' and '.' in patterns?
> >
> > -- hendrik
> >
> >
> > ___
> > Monotone-devel mailing list
> > Monotone-devel@nongnu.org
> > http://lists.nongnu.org/mailman/listinfo/monotone-devel
> >

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

Re: [Monotone-devel] branch patterns

[Hendrik Boom]

On Sun, Mar 27, 2011 at 10:48:34AM +0200, Richard Levitte wrote:
> In message <20110327004909.ga26...@topoi.pooq.com> on Sat, 26 Mar 2011 
> 20:49:09 -0400, Hendrik Boom  said:
> 
> hendrik> pattern "com.pooq.hendrik.write*"
> hendrik> 
> hendrik> doesn't work, but
> hendrik> 
> hendrik> pattern "com.pooq.hendrik.write.*"
> hendrik> 
> hendrik> does when I'm trying to sync branches
> hendrik> 
> hendrik> com.pooq.hendrik.write.melinda
> 
> Please show the exact command, that might tell us more.

OK.  Here goes:

Every time the serve command is

mtn --db ~/monotone/write.db -k hend...@topoi.pooq.com serve

and the client-side sync command is

mtn sync

And I did remember to restart the server for each run, after changing 
read-permissions.


When on the server the read-permissions reads as follows

hendrik@april:~/monotone$ cat ~/.monotone/read-permissions
pattern "com.pooq.hendrik.write*"
allow "hend...@topoi.pooq.com"
allow "hendrik-port...@topoi.pooq.com"
allow "hend...@notlookedfor.topoi.pooq.com


hendrik@april:~/monotone$ 


thee output from sync is:

hendrik@notlookedfor:~/write/Melinda$ mtn sync
mtn: connecting to mtn://topoi.pooq.com
mtn: finding items to synchronize:
mtn: certificates | keys | revisions
mtn:  192 |3 |64
mtn: warning: protocol error while processing peer mtn://topoi.pooq.com: 
'received network error: denied 'ad968be7244234e8d653201ab1ddd33b53ffa04d' read 
permission for '*' excluding '' because of branch 
'com.pooq.hendrik.write.melinda''
mtn:  bytes in | bytes out | revs in
mtn:   167 |   328 |   0
mtn: error: processing failure while talking to peer mtn://topoi.pooq.com, 
disconnecting
hendrik@notlookedfor:~/write/Melinda$ 


whereas with this read-permissions file on the server

hendrik@april:~/.monotone$ cat read-permissions
pattern "com.pooq.hendrik.write.*"
allow "hend...@topoi.pooq.com"
allow "hendrik-port...@topoi.pooq.com"
allow "hend...@notlookedfor.topoi.pooq.com"
hendrik@april:~/.monotone$ 

sync produces:

hendrik@notlookedfor:~/write/Melinda$ mtn sync
mtn: connecting to mtn://topoi.pooq.com
mtn: finding items to synchronize:
mtn: certificates | keys | revisions
mtn:  192 |3 |64
mtn:  bytes in | bytes out | revs in | revs out
mtn: 1.1 k | 1.4 k | 0/0 |  0/0
mtn: successful exchange with mtn://topoi.pooq.com
mtn: note: your workspace has not been updated
hendrik@notlookedfor:~/write/Melinda$ 



> 
> hendrik> Why?  What are the rules for '*' and '.' in patterns?
> 
> The same as bash globs.

So "." should match a period, and "*" matches zero or more characters.
That's what I thought.  Bash has some special rules about filenames 
starting with a dot.  Could they be tripping me up?

-- hendrik

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

Re: [Monotone-devel] branch patterns

[Hendrik Boom]

Forgot to mentin versions.  Just noticed the server is running 0.99.1

hendrik@april:~/monotone$ mtn --version
monotone 0.99.1 (base revision: 8973482283db7c36780dce2b54721ccc0f5b7388)
hendrik@april:~/monotone$ 

whereas the client is running 0.48:

hendrik@notlookedfor:~$ mtn --version
monotone 0.48 (base revision: 844268c137aaa783aa800a9c16ae61edda80ecea)
hendrik@notlookedfor:~$ 

Could this be the problem?

On Sun, Mar 27, 2011 at 
09:54:52AM -0400, Hendrik Boom wrote:
> On Sun, Mar 27, 2011 at 10:48:34AM +0200, Richard Levitte wrote:
> > In message <20110327004909.ga26...@topoi.pooq.com> on Sat, 26 Mar 2011 
> > 20:49:09 -0400, Hendrik Boom  said:
> > 
> > hendrik> pattern "com.pooq.hendrik.write*"
> > hendrik> 
> > hendrik> doesn't work, but
> > hendrik> 
> > hendrik> pattern "com.pooq.hendrik.write.*"
> > hendrik> 
> > hendrik> does when I'm trying to sync branches
> > hendrik> 
> > hendrik> com.pooq.hendrik.write.melinda
> > 
> > Please show the exact command, that might tell us more.
> 
> OK.  Here goes:
> 
> Every time the serve command is
> 
> mtn --db ~/monotone/write.db -k hend...@topoi.pooq.com serve
> 
> and the client-side sync command is
> 
> mtn sync
> 
> And I did remember to restart the server for each run, after changing 
> read-permissions.
> 
> 
> When on the server the read-permissions reads as follows
> 
> hendrik@april:~/monotone$ cat ~/.monotone/read-permissions
> pattern "com.pooq.hendrik.write*"
> allow "hend...@topoi.pooq.com"
> allow "hendrik-port...@topoi.pooq.com"
> allow "hend...@notlookedfor.topoi.pooq.com
> 
> 
> hendrik@april:~/monotone$ 
> 
> 
> thee output from sync is:
> 
> hendrik@notlookedfor:~/write/Melinda$ mtn sync
> mtn: connecting to mtn://topoi.pooq.com
> mtn: finding items to synchronize:
> mtn: certificates | keys | revisions
> mtn:  192 |3 |64
> mtn: warning: protocol error while processing peer mtn://topoi.pooq.com: 
> 'received network error: denied 'ad968be7244234e8d653201ab1ddd33b53ffa04d' 
> read permission for '*' excluding '' because of branch 
> 'com.pooq.hendrik.write.melinda''
> mtn:  bytes in | bytes out | revs in
> mtn:   167 |   328 |   0
> mtn: error: processing failure while talking to peer mtn://topoi.pooq.com, 
> disconnecting
> hendrik@notlookedfor:~/write/Melinda$ 
> 
> 
> whereas with this read-permissions file on the server
> 
> hendrik@april:~/.monotone$ cat read-permissions
> pattern "com.pooq.hendrik.write.*"
> allow "hend...@topoi.pooq.com"
> allow "hendrik-port...@topoi.pooq.com"
> allow "hend...@notlookedfor.topoi.pooq.com"
> hendrik@april:~/.monotone$ 
> 
> sync produces:
> 
> hendrik@notlookedfor:~/write/Melinda$ mtn sync
> mtn: connecting to mtn://topoi.pooq.com
> mtn: finding items to synchronize:
> mtn: certificates | keys | revisions
> mtn:  192 |3 |64
> mtn:  bytes in | bytes out | revs in | revs out
> mtn: 1.1 k | 1.4 k | 0/0 |  0/0
> mtn: successful exchange with mtn://topoi.pooq.com
> mtn: note: your workspace has not been updated
> hendrik@notlookedfor:~/write/Melinda$ 
> 
> 
> 
> > 
> > hendrik> Why?  What are the rules for '*' and '.' in patterns?
> > 
> > The same as bash globs.
> 
> So "." should match a period, and "*" matches zero or more characters.
> That's what I thought.  Bash has some special rules about filenames 
> starting with a dot.  Could they be tripping me up?
> 
> -- hendrik
> 
> ___
> Monotone-devel mailing list
> Monotone-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/monotone-devel

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

Re: [Monotone-devel] branch patterns

[Hendrik Boom]

On Sun, Mar 27, 2011 at 06:08:50PM +0200, Richard Levitte wrote:
> In message <20110327135452.ga22...@topoi.pooq.com> on Sun, 27 Mar 2011 
> 09:54:52 -0400, Hendrik Boom  said:
> 
> hendrik> OK.  Here goes:
> hendrik> 
> hendrik> Every time the serve command is
> hendrik> 
> hendrik> mtn --db ~/monotone/write.db -k hend...@topoi.pooq.com serve
> hendrik> 
> hendrik> and the client-side sync command is
> hendrik> 
> hendrik> mtn sync
> hendrik> 
> hendrik> And I did remember to restart the server for each run, after 
> changing 
> hendrik> read-permissions.
> hendrik> 
> hendrik> 
> hendrik> When on the server the read-permissions reads as follows
> hendrik> 
> hendrik> hendrik@april:~/monotone$ cat ~/.monotone/read-permissions
> hendrik> pattern "com.pooq.hendrik.write*"
> hendrik> allow "hend...@topoi.pooq.com"
> hendrik> allow "hendrik-port...@topoi.pooq.com"
> hendrik> allow "hend...@notlookedfor.topoi.pooq.com
> hendrik> 
> hendrik> 
> hendrik> hendrik@april:~/monotone$ 
> hendrik> 
> hendrik> 
> hendrik> thee output from sync is:
> hendrik> 
> hendrik> hendrik@notlookedfor:~/write/Melinda$ mtn sync
> hendrik> mtn: connecting to mtn://topoi.pooq.com
> hendrik> mtn: finding items to synchronize:
> hendrik> mtn: certificates | keys | revisions
> hendrik> mtn:  192 |3 |64
> hendrik> mtn: warning: protocol error while processing peer 
> mtn://topoi.pooq.com: 'received network error: denied 
> 'ad968be7244234e8d653201ab1ddd33b53ffa04d' read permission for '*' excluding 
> '' because of branch 'com.pooq.hendrik.write.melinda''
> hendrik> mtn:  bytes in | bytes out | revs in
> hendrik> mtn:   167 |   328 |   0
> hendrik> mtn: error: processing failure while talking to peer 
> mtn://topoi.pooq.com, disconnecting
> hendrik> hendrik@notlookedfor:~/write/Melinda$ 
> hendrik> 
> hendrik> 
> hendrik> whereas with this read-permissions file on the server
> hendrik> 
> hendrik> hendrik@april:~/.monotone$ cat read-permissions
> hendrik> pattern "com.pooq.hendrik.write.*"
> hendrik> allow "hend...@topoi.pooq.com"
> hendrik> allow "hendrik-port...@topoi.pooq.com"
> hendrik> allow "hend...@notlookedfor.topoi.pooq.com"
> hendrik> hendrik@april:~/.monotone$ 
> hendrik> 
> hendrik> sync produces:
> hendrik> 
> hendrik> hendrik@notlookedfor:~/write/Melinda$ mtn sync
> hendrik> mtn: connecting to mtn://topoi.pooq.com
> hendrik> mtn: finding items to synchronize:
> hendrik> mtn: certificates | keys | revisions
> hendrik> mtn:  192 |3 |64
> hendrik> mtn:  bytes in | bytes out | revs in | revs out
> hendrik> mtn: 1.1 k | 1.4 k | 0/0 |  0/0
> hendrik> mtn: successful exchange with mtn://topoi.pooq.com
> hendrik> mtn: note: your workspace has not been updated
> hendrik> hendrik@notlookedfor:~/write/Melinda$ 
> 
> Thanks.  That does seem weird, but to make sure we have all details,
> what output do you get on the client side if you do this?
> 
>   mtn ls vars

When I do this client-side command outside of a workspace, no output at 
all.  But when I do it in the same workspace I reported on before, 
there's a whole lot of stuff.  Is this normal, or is there a lot of 
historical cruft that might be getting in the way?

hendrik@notlookedfor:~/write/Melinda$ ls
Melinda  _MTN
hendrik@notlookedfor:~/write/Melinda$ mtn ls vars
database: default-exclude-pattern 
database: default-include-pattern *
database: default-server mtn://topoi.pooq.com
known-servers: 172.25.1.11 599ec98e8155a17f3bbf177de27a409d4824
known-servers: 4691://topoi.pooq.com/write 
599ec98e8155a17f3bbf177de27a409d4824
known-servers: mtn://topoi.pooq.com 599ec98e8155a17f3bbf177de27a409d4824
server-exclude: 172.25.1.11 
server-exclude: 4691://topoi.pooq.com/write 
server-exclude: monotone://topoi.pooq.com/write 
server-exclude: mtn://topoi.pooq.com 
server-exclude: mtn://topoi.pooq.com/write 
server-exclude: ssh://hendrik@172.25.1.4/~hendrik/monotone/write.db 
server-include: 172.25.1.11 *
server-include: 4691://topoi.pooq.com/write *
server-include: monotone://topoi.pooq.com/write *
server-include: mtn://topoi.pooq.com *
server-include: mtn://topoi.pooq.com/write *
server-include: ssh://hendrik@172.25.1.4/~hendrik/monotone/write.db *
hendrik@notlookedfor:~/write/Melinda$ 

> 
> hendrik> > hendrik> Why?  What are the rules for '*' and '.' in patterns?
> hendrik> > 
> hendrik> > The same as bas

Re: [Monotone-devel] branch patterns

[Hendrik Boom]

On Sun, Mar 27, 2011 at 06:08:50PM +0200, Richard Levitte wrote:
> 
> Thanks.  That does seem weird, but to make sure we have all details,
> what output do you get on the client side if you do this?
> 
>   mtn ls vars

Just to be clear:  I have got monotone and usher to be sufficiently 
functional now, and they work together.  This * vs. .* problem occurs 
when I use monotone by itself, without usher.  (I don't know if it's a 
problem when I do use usher).

I'd be happy to run further tests to resolve the * vs .* problem in 
order to help track down potential problems, although it's not a matter 
of extreme urgency for me.  If there's some other more urgent problem, 
by all means work on it first.

-- hendrik

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

Re: [Monotone-devel] Confusing terminology between usher and monotone and proposed change

[Hendrik Boom]

On Thu, May 05, 2011 at 06:57:10PM -0400, Stephen Leake wrote:
> Richard Levitte  writes:
> 
> > I've had a closer look at the terminology used in usher and in
> > monotone, and there is a part that's quite confusing:
> >
> > In usher terminology, different databases are served by different
> > monotone server, and therefore, the URI to access them through a
> > server name would be expressed as mtn://HOST/SERVER?PATTERN.
> >
> > In monotone terminology, the same URI is expressed as
> > mtn://HOST/PATH?PATTERN.
> >
> > Furthermore, usher is a server in its own right, so when talking about
> > the usher+monotone combination, it might be confusing to talk about a
> > server, as it might not always be clear if you're talking about the
> > usher server itself or one of the underlying monotone servers.
> >
> > Also, in usherctl, the confusion is increased, since it uses PROJECT
> > to designate what usher calls SERVER and monotone calls PATH.  This is
> > confusing since monotone has another idea of what a project is, and
> > will just increase as soon as policy branches are in place.
> >
> >
> > To clear the confusion, I propose that we make a terminology change in
> > usher, where the term SERVER (to designate a monotone server entry in
> > the usher configuration) be changed to PATH (with the implicit
> > understanding that a PATH is then served by the monotone server in
> > said entry).  This makes it clear how it corresponds to what's in the
> > monotone documentation and leaves less (if any) confusion about what
> > server you're talking about in different contexts.  And frankly, I
> > like the ring of it ;-)
> >
> > The proposed changed involves having the key 'server' be replaced by
> > 'path' in usher's configuration file.  Of course, usher should still
> > understand the key 'server' for a while (say, until 2.0), but will
> > then tell the user that it's deprecated and should be replaced.
> > usherctl will be changed in a corresponding way.
> >
> > This should be implemented before releasing usher 1.0.
> >
> >
> > Thoughts?
> 
> looks good to me, but then I've never implemented an usher setup.

Well, even though I thought I got it to work last month, I'm still 
trying to figure out my usher setup (I probably forgot soemthing about 
how I used it) and I've found everything confusing again.  I'll retry 
understanding it with Richard's not in hand, and I'll tell you if it's 
become clear not in a few days.

Maybe this letter came just in time for me!

-- hendrik

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

Re: [Monotone-devel] Confusing terminology between usher and monotone and proposed change

[Hendrik Boom]

On Thu, May 05, 2011 at 10:42:41AM +0200, Richard Levitte wrote:
> I've had a closer look at the terminology used in usher and in
> monotone, and there is a part that's quite confusing:
> 
> In usher terminology, different databases are served by different
> monotone server, and therefore, the URI to access them through a
> server name would be expressed as mtn://HOST/SERVER?PATTERN.
> 
> In monotone terminology, the same URI is expressed as
> mtn://HOST/PATH?PATTERN.
> 
> Furthermore, usher is a server in its own right, so when talking about
> the usher+monotone combination, it might be confusing to talk about a
> server, as it might not always be clear if you're talking about the
> usher server itself or one of the underlying monotone servers.
> 
> Also, in usherctl, the confusion is increased, since it uses PROJECT
> to designate what usher calls SERVER and monotone calls PATH.  This is
> confusing since monotone has another idea of what a project is, and
> will just increase as soon as policy branches are in place.
> 
> 
> To clear the confusion, I propose that we make a terminology change in
> usher, where the term SERVER (to designate a monotone server entry in
> the usher configuration) be changed to PATH (with the implicit
> understanding that a PATH is then served by the monotone server in
> said entry).

This would presumably be the server name in the "server" line.  The 
"foo" in 
server "foo"

But the word "path" is in common usage to a sequence of directory names 
separated by slashes, possibly ending in a file name.

This still leaves room for confusion, since (unless I'm grossly 
confused) it's not the file name of the data base that's wanted here.

-- hendrik

>  This makes it clear how it corresponds to what's in the
> monotone documentation and leaves less (if any) confusion about what
> server you're talking about in different contexts.  And frankly, I
> like the ring of it ;-)
> 
> The proposed changed involves having the key 'server' be replaced by
> 'path' in usher's configuration file.  Of course, usher should still
> understand the key 'server' for a while (say, until 2.0), but will
> then tell the user that it's deprecated and should be replaced.
> usherctl will be changed in a corresponding way.
> 
> This should be implemented before releasing usher 1.0.
> 
> 
> Thoughts?
> 
> Cheers,
> Richard ( my main focus in the nearest future will be to implement
> that change, as well as changing the test structure (already working
> on it) )
> 
> -- 
> 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
> https://lists.nongnu.org/mailman/listinfo/monotone-devel

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

Re: [Monotone-devel] Confusing terminology between usher and monotone and proposed change

[Hendrik Boom]

On Tue, May 10, 2011 at 09:09:15AM +0200, Richard Levitte wrote:
> 
> With my idea (just for the sake of being explicit), the following:
> 
> server "newpub"
> local "--confdir" "/home/levitte/usher.projects/newpub" "-d" 
> "/home/levitte/usher.projects/newpub/database.mtn" "--no-standard-rcfiles" 
> "--rcfile" "/home/levitte/usher.projects/newpub/monotonerc" "--timestamps" 
> "--ticker=dot"
> 
> would be replaced with:
> 
> path "newpub"
> local "--confdir" "/home/levitte/usher.projects/newpub" "-d" 
> "/home/levitte/usher.projects/newpub/database.mtn" "--no-standard-rcfiles" 
> "--rcfile" "/home/levitte/usher.projects/newpub/monotonerc" "--timestamps" 
> "--ticker=dot"
> 
> In human terms, the former would be expressed "this is the server
> named 'newpub', and local indicates how to start it."  The latter
> would be "the path 'newpub' is served with a monotone started with the
> arguments given by local."
> 
> hendrik> But the word "path" is in common usage to a sequence of
> hendrik> directory names separated by slashes, possibly ending in a
> hendrik> file name.
> 
> The word "path" has been expanded, especially if we speak in URI
> terms, to something of a structured notation to reach a specific
> resource within a specific realm.  That's exactly the way PATH is
> used in mtn://HOST/PATH?PATTERN .

This answers my objection to the word "path".  Framing the ter+minology 
this way removes the confusin.

-- hendrik

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

[Monotone-devel] permissions and identity

[Hendrik Boom]

I'm using usher with monotone.
Do I have it right?

User identities (the public keys) are kept in the monotone databases.  
Presumably every database can have different sets of user identities.  

But private keys are kept in a .monotone/keys directory, which is the 
same for all databases.

So the databases can differ as to public keys, but have to agree on 
provate keys.

Finally, the set of branches users can read and write to is kept in 
files different directry, .monotone/read-permissions and 
.monotone/write-permissions.  This even though moltiple data bases 
probably provide completely different branches.


Is there a rationale for this division of responsibilities, or did it 
just appear more or less by accident?

-- hendrik


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

Re: [Monotone-devel] GPLv3 code in monotone

[Hendrik Boom]

On Thu, May 19, 2011 at 07:42:12AM -0400, Stephen Leake wrote:
> Thomas Keller  writes:
> 
> > Hi!
> >
> > This is a follow-up on
> > , where I was asked
> > to clarify the license of the openSUSE monotone package.
> >
> > Currently, this is stating GPLv2+, but the reporter needs some
> > clarification because we have some GPLv3+ code in the package
> > (src/{unix,win32}/parse_date.cc). From the original ticket:
> >
> >  
> >
> > I then answered that the files are used (a) and that it was not an
> > accident (c), but I'm unsure about the "derived work" clause. I'm seeing
> > the following solutions (ordered by impact):
> >
> > 1) document in README or somewhere else that parts of the code use
> > GPLv3+ and give packagers a hint what license they should use when they
> > package monotone
> > 2) relicense the mentioned files as GPLv2+
> > 3) relicense everything of mtn GPLv3+
> >
> > Opinions anyone?
> 
> I put that there, mostly as a response to Richard Stallman's plea for
> all Gnu packages to be upgraded to GPL v3 (yes, I know monotone is not a
> Gnu package).
> 
> I also raised the issue of upgrading the package generally (I can't find
> it in the mailing list archive). There was some objection, but not much
> discussion.
> 
> All authors have already given permission to use GPLv3, since the other
> files are GPLv2+.
> 
> I think GPLv3 is a better license; it is clearer, and has better
> mechanisms for exceptions (not that we need any).
> 
> Hmm. src/boost/* are _not_ GPL; they are "any use, with notice".
> 
> similarly, src/netxx/* are not GPL.
> 
> There has been some discussion of the issue of multiple licenses in a
> package on the Debian policy list. The consensus seems to be that there
> is no such thing as "the overall license"; each file has its own
> license. That is, the unit of reuse is the file, not the package. They
> are working on upgrading the package documentation format to make it
> easy to describe what license applies to each file.
> 
> I think that discussion applies to source distribution. Since we also
> distribute a binary, it must have some single license. I have not seen a
> discussion of that.
> 
> I'm guessing the monotone binary should be GPLv3, since the GPL v3 file
> does not say "or earlier", and the GPLv2+ and non-GPL files are
> compatible with GPL v3.
> 
> I don't feel strongly either way; if it makes life simpler, I agree to
> relicense src/{unix,win32}/parse_date.cc as GPLv2+.

Yes, at present the linked monotone binary will have to be released as 
GPLv3.  And the source files, except for src/{unix,win32}/parse_date.cc, 
are GPLv2+.  I see no reason to relicence most of the source files, 
unless we specifically want to forbid anyone to use them within other 
GPLv2 software.  But if we want to permit such reuse, it would be 
gracious to relicense the two exceptions as GPLv2+.

-- hendrik

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

Re: [Monotone-devel] GPLv3 code in monotone

[Hendrik Boom]

On Fri, May 20, 2011 at 04:53:59PM -0700, Zack Weinberg wrote:
> On 2011-05-20 4:46 PM, Stephen Leake wrote:
>> GPLv3 was heavily reviewed before it was released, and has been out for
>> almost 4 years.
>>
>> Can you elaborate?
>>
>> I'm sure there are good reasons not to bother going to GPLv3, but I
>> don't understand what you mean by "premature".
>
> Switching to GPL3 would make us license-incompatible with a large body  
> of code (everything under a copyleft that isn't v3-compatible, in  
> particular, code under v2-only).  It would also make us  
> license-compatible with a large body of code (anything that adds  
> restrictions that are okay with v3 but not v2).

GLP2+ is compatible with GPL2.
GLP2+ is compatible with GPL3.

-- hendrik

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

Re: [Monotone-devel] GPLv3 code in monotone

[Hendrik Boom]

On Fri, May 20, 2011 at 07:18:21PM -0700, Zack Weinberg wrote:
> On Fri, May 20, 2011 at 6:51 PM, Hendrik Boom  wrote:
> >> Switching to GPL3 would make us license-incompatible with a large body
> >> of code (everything under a copyleft that isn't v3-compatible, in
> >> particular, code under v2-only).  It would also make us
> >> license-compatible with a large body of code (anything that adds
> >> restrictions that are okay with v3 but not v2).
> >
> > GLP2+ is compatible with GPL2.
> > GLP2+ is compatible with GPL3.
> 
> I said v2-only.

Yes, we're in agreement.  The v2-only item was at the end of my first 
sentence.  The mtn code should be GPL2+, mentioned at the start of both 
sentences.

Sorry if that wasn't clear.

-- hendrik

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

[Monotone-devel] New branch name with no other changes

[Hendrik Boom]

I checked out a new workspace, and I want to check it in again unchenged 
with a new branch name  -- the one I want to use to make changes.  I'd 
like to make it clear that the new branch is starting in the same state 
as the current head in the old one.

But when I try to check in, it fails:

hendrik@notlookedfor:~/fanfic/theShadowChronicles-MarkMacKinnon/edited$ 
mtn commit 
--branch=com.pooq.hendrik.othersfanfic.theShadowChronicles.cleanup
mtn: misuse: no changes to commit

Well, yes, there were no changes in any of the files, but the branch was 
different.

Is there some conceptual reason why a branch name change should not be 
enough to do a commit?

Of course I can get on with my work by making a small inessential 
change, but this is inelegant.  I'll do it, though, when time presses. 

-- hendrik


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

Re: [Monotone-devel] New branch name with no other changes

[Hendrik Boom]

On Thu, Jun 09, 2011 at 02:14:16PM -0400, Hendrik Boom wrote,

but forgot to mention he was using mtn 1.0:

> I checked out a new workspace, and I want to check it in again unchenged 
> with a new branch name  -- the one I want to use to make changes.  I'd 
> like to make it clear that the new branch is starting in the same state 
> as the current head in the old one.
> 
> But when I try to check in, it fails:
> 
> hendrik@notlookedfor:~/fanfic/theShadowChronicles-MarkMacKinnon/edited$ 
> mtn commit 
> --branch=com.pooq.hendrik.othersfanfic.theShadowChronicles.cleanup
> mtn: misuse: no changes to commit
> 
> Well, yes, there were no changes in any of the files, but the branch was 
> different.
> 
> Is there some conceptual reason why a branch name change should not be 
> enough to do a commit?
> 
> Of course I can get on with my work by making a small inessential 
> change, but this is inelegant.  I'll do it, though, when time presses. 
> 
> -- hendrik
> 
> 
> ___
> Monotone-devel mailing list
> Monotone-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/monotone-devel

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