Re: (LONG-ish) Bringing cvsnt mergepoint processing into CVS: request for feedback

[Mark D. Baushke]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Phil Richards <news@derived-software.ltd.uk> writes:

> Inter-merging between two branches works (roughly) the same way -
> in practice it is possible to merge main-to-branch and branch-to-main
> repreatedly and it all does what would be expected (it works by
> identifying the most recent common mergepoint, and using that as the
> starting point for the merge).
> 
> 
> The main limitations/problems/issues as I see them[*]:
>  * During the "cvs update -j"->"cvs commit" stage, the merge point
>    is recorded in CVS/Entries.Extra (a new file).
>  * Merging from main-to-branch1, main-to-branch2, and then
>    branch1-to-branch2 will not do the "right" thing.  
>  * Performing multiple cvs update -j's, from different branches,
>    without a intermediary commit will confuse things.
> 
> The first point is not a problem, as such, but it would be nice to
> eliminate the need for another pair of files (Entries.Extra and the .Log
> version) that need to be kept in step with Entries.  A possible approach
> might be to reuse/extend the "+CONFLICT" part of the timestamp field,
> but I think the knock-on effects are probably going to cause grief for 
> other clients.  This is one where I would really appreciate some
> 
> The second point is a usability issue, but resolving it is (at first
> and second look) distinctly non-trivial. Would it be acceptable for
> the first cut of any core CVS approach to keep this limitation?

No. Or, ast least I think I would rather see it designed correctly
before it is implemented in case the implementation needs to be adjusted
to resolve the problem.

> The third point is not really that important - the workaround is
> trivial and good practice anyway: just commit each merge after they
> are done.
> 
> 
> The bigger question: does anybody actually want "mergepoint" processing
> adding into core CVS apart from me?

Yes.

> Any thoughts/suggestions?

A question... I seem to recall that CvsNT records a new 'mergepoint'
keyword into the RCS format and that such ,v files thereafter had
problems with normal RCS command operating on them (although it may have
been the 'commitid: <hashvalue>;' that was the real culprit when I last
looked. Could you answer if you are adding a new keyword to the RCS
structure or not?

        -- Mark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (FreeBSD)

iD8DBQFAMpkx3x41pRYZE/gRAkPbAKCFjaDbt24Mtzv3ECqeNkUX7GcSqgCg4lOj
xDP8Qd+gLOdhivIaBYWZFxU=
=iFO+
-----END PGP SIGNATURE-----