> +-------------+ pull +-------------+ pull +--------------+
> | onnv-clone |------>| workstation |----->| bld. machine |
> | | | repo | | repo |
> +-------------+ +-------------+ +--------------+
>
> This means doing 'hg commit' instead of 'hg backup' and 'hg pull -u'
> instead of 'wx restore -f'.
>
> 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.
That's true. But you don't need to recommit all the time. Just before
final putback should be fine. If you commit often in your workspace, it
gives you the ability to see how the fix evolved over time.
Generally both approaches are valid
a) hg bundle -> hg unbundle / hg strip
b) hg commit -> hg pull
Third possibility is using Mercurial Queues and don't use cdm at all
(only for pbchk).
--
Vlad
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 193 bytes
Desc: not available
URL:
<http://mail.opensolaris.org/pipermail/scm-migration-dev/attachments/20080820/1c9273f5/attachment.bin>
