Fwd: [Monotone-devel] Cvssync problems

[Bill Marquette]

Ooopps...reply-all :)

---------- Forwarded message ----------
From: Bill Marquette <address@hidden>
Date: Sep 30, 2005 10:53 AM
Subject: Re: [Monotone-devel] Cvssync problems
To: Christof Petig <address@hidden>


On 9/30/05, Christof Petig <address@hidden> wrote:
> > it.  The most annoying of which are the branch propagation ones
> > (http://cvstrac.pfsense.com/chngview?cn=6478 for instance) which end
> > up telling me nothing about the change (part of that message may be
> > due to some of the changelog recursion that I removed).
>
> Some time ago merges only commited with "merge of X and Y" which was
> totally meaningless to CVS users. So I started to collect the part of
> the history which is unknown to the CVS server. Propagate was not on my
> mind when I designed this :-(

lol, leave it to the users to find the issues :)

> Is it correct that propagates should not mention their history. Perhaps
> a settable log gathering depth is a good idea.

That I'm not sure of, I can only speak to how I envisioned using this.

Do a monotone cvs_takeover/cvs_pull
checkout the code into a seperate work branch
work, commit, work some more, commit
become happy with changes
sync cvs checkout branch with cvs server
pull cvs branch changes into work branch
propagate work branch changes back into cvs branch
and finally cvs_push

If instead of pulling the changelog from the last monotone commit (in
this case the propagate) I can specify my own changelog entry (-m
maybe?) I'd be set.

> To design a user interface for this feature is not easy (especially
> since you might push multiple steps with one command).

I'd be happy with a flag...or cvs_push dumping the changelog entry
it's about to commit into $EDITOR for final edit before push.  Maybe
this can be done in lua, I don't know enough about the hooks there
either.

--Bill