Re: [Monotone-devel] Interoperating with upstream open-source projects

[Shaun Jackman]

On 4/13/05, Nathaniel Smith <address@hidden> wrote:
> On Wed, Apr 13, 2005 at 11:05:51AM -0600, Shaun Jackman wrote:
> > Is it possible to attach a name to an e-mail address in a key? For
> > example, I tried...
> > $ monotone --db=.mt genkey 'Shaun Jackman <address@hidden>'
> > monotone: misuse: error converting 23 UTF-8 bytes to IDNA ACE: non-LDH
> > characters
> > ... with no luck.
> 
> No, as you discovered.  Is there a particular reason you need this,
> or?

When reading change logs, I find names more personal and easier to
"parse" than an email address, especially when the email address is
initials or some such. More importantly though, the purpose is to
maintain enough information to automatically generate a ChangeLog from
a Monotone log. A ChangeLog contains the name, email address, and date
of the change. Monotone currently provides the latter two but not the
first.

> Your best bet here would be to override the hook "edit_comment"
> (described at http://www.venge.net/monotone/docs/Hook-Reference.html).
> The "commentary" argument it gets is the text of the revision being
> committed, which is in a reasonably easily parseable format; you could
> write a little bit of lua (or write an external program, and then
> write some lua to call out to it) that takes revision text and
> generates you a changelog template.  (Presumably you would also teach
> this code to figure out your name and email address, or just hard code
> them.)

Thanks! I'll look into this. Is there a public directory of
contributed community hook recipes?

> It sounds like you want to create a branch for each unrelated change.
> Something like:
>   $ monotone --branch=com.host.project.upstream checkout change1
>   $ monotone --branch=com.host.project.upstream checkout change2
>   <poke around editing things in change1 and change2>
>   .../change1$ monotone --branch=com.other.local.change1 commit
>   .../change2$ monotone --branch=com.other.local.change2 commit

In this example I have a working copy for each patch. This is fine for
the purpose of editing and submitting each patch, but I'll also want a
working copy that incorporates all these patches for my own actual
day-to-day use -- and to a lesser degree to test that the patches can
co-exist. Can I have a working copy that merges the branches without
merging them in the repository? Or if I do merge in the repository,
which could be useful, is it still possible to generate a diff of the
changes for that patch branch from pre-merge straight through to new
changes post-merge without dragging in changes from the other patch
branches

> Now you can diff between these files and the version you originally
> branched from (you can get the branch point from "monotone log", or
> monotone-viz), and mail that into the list.  When you want to modify
> the patch more, make some more changes on either branch, and then
> regenerate the patch the same way to send in for more feedback.  If
> there are changes made upstream along the way, that you want to merge
> into your local work (so your patch stays current), just say
>   $ monotone propagate com.host.project.upstream com.other.local.change1

Great! And if the upstream project distributes its source in tarballs,
you simply maintain a .upstream branch and merge with that. (right?)
 
> > One final thing. What's the selector for an empty file, and what's the
> > selector for the current merged head? I'm looking for something that
> > looks like monotone diff -r empty -r head hello.c.
> 
> There is no selector for the current head.  It's kinda an obvious
> lack, but no-one's gotten around to adding it.  (Patches accepted.)
> 
> I'm not sure what you mean by "empty file selector"; selectors are for
> whole revisions, not individual files.  If you just want to get the
> contents of hello.c in some revision, you can say
>   $ monotone cat file REVISION-ID-OR-SELECTOR hello.c

I was trying to generate a diff for a new file, and I was trying...
$ monotone diff -r FILE-ID -r FILE-ID
which left me wondering what the FILE-ID for the file was before it
existed, or while it was still empty. I see now that diff -r takes
REVISION-ID and not FILE-ID, which makes sense.

Thanks for your detailed response, Nathaniel. I'm really looking
forward to finally using a distributed source system that I enjoy!

Cheers,
Shaun