Vladimir Kotal writes:
> Like this ?
>
> +-------------+ pull +-------------+ pull +--------------+
> | onnv-clone |------>| workstation |----->| bld. machine |
> | | | repo | | repo |
> +-------------+ +-------------+ +--------------+
Yes.
> This means doing 'hg commit' instead of 'hg backup' and 'hg pull -u'
> instead of 'wx restore -f'.
Right.
> There is little problem with this approach however: while sequence of
> commits is fine, recommit forces a merge on the build machine side (and
> multiple recommit's are normal, e.g. during code review process to
> generate new webrev). wx restore does not have this problem because it
> overrides both metadata and data. Yeah, Mercurial is not Teamware (or
> SCCS), but still.
You can:
- avoid doing a recommit until the last moment necessary.
- remember to do an "hg rollback" in the build machine repository
(to undo the last pull) right before pulling again.
and/or:
- simply rm -rf the build machine repository after a
history-destroying recommit, pull from a local onnv clone to seed,
then pull anew from the workstation repository.
For what it's worth, I worked for a while with the rollback mechanism,
but I found I like the rm -rf tactic better.
--
James Carlson, Solaris Networking <james.d.carlson at sun.com>
Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
