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

[Nathaniel Smith]

On Thu, Apr 14, 2005 at 11:23:56AM -0600, Shaun Jackman wrote:
> On 4/13/05, Nathaniel Smith <address@hidden> wrote:
> > 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?

I think we'd be happy to distribute them in monotone's contrib/
directory, for now...

> > 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

The working copies aren't actually the really important part, they're
just convenient; the important part is that you have a separate branch
for each patch.

If you want to create a "n+1th" branch, that's the union of all the
other one's that's easy too.  Just do something like:
  $ monotone --branch=com.host.project.change1 checkout combined
  .../combined$ monotone --branch=com.other.local.combined commit
  $ monotone propagate com.other.local.change2 com.other.local.combined
  $ monotone propagate com.other.local.change3 com.other.local.combined
  etc.

Hmm, this is displeasingly non-symmetric between the first branch and
the later ones... maybe there are ways to make this a little more
ergonomic, but hopefully you get the idea.

Just remember to always make commits in the patch branches, and then
propagate them to the combined branch; that way you'll still have them
separated out and easy to diff etc.

> > 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?)

Yes.

> > > 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.

Ah, yes.  Is there anywhere in particular the documentation is
misleading about this, or could be more clear?

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

I hope you do :-).

-- Nathaniel

-- 
So let us espouse a less contested notion of truth and falsehood, even
if it is philosophically debatable (if we listen to philosophers, we
must debate everything, and there would be no end to the discussion).
  -- Serendipities, Umberto Eco