[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: (LONG-ish) Bringing cvsnt mergepoint processing into CVS: request fo
From: |
Mark D. Baushke |
Subject: |
Re: (LONG-ish) Bringing cvsnt mergepoint processing into CVS: request for feedback |
Date: |
Tue, 17 Feb 2004 14:44:01 -0800 |
-----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-----