--I/wet25DnWlSyk1C
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Jul 30, 2007 at 06:34:41PM -0400, David Maxwell wrote:
> On Tue, Jul 31, 2007 at 08:02:02AM +1000, Daniel Carosone wrote:
> > None of these things makes fixing the problem of correctly importing
> > cvs history any easier, but it does seem to diminish the motivation to
> > do so when people are apparently so readily accepting of such
> > information loss.
>=20
> I don't think that svn means to suggest that you 'should' be willing to
> lose history, only that many people seem okay with it. Hence there has
> been little motivation for others to improve cvs2svn.

Yes, that's exactly what I meant. =20

The rest of my commentary, with regard to merge deficiencies and the
need for external processes/tools, were not specific to svn. They
certainly apply to svn today, in as much as it historically intended
to reimplement much of cvs and carried those deficiencies along with
it.

Practices to work around these limitations outside the core VCS (and
their embodiment in tools like quilt) emerged.  The strongest
criticism of svn you could levy in this regard is simply that it
missed the ambition to address this directly.  It's only the more
recent crop of VCS tools that seek to encompass this broader scope (in
various ways), and I know that svn has been looking very closely at
the merging issue for future development.

> > I've always assumed we're not so accepting, am I wrong?
>=20
> I'm with you. I mentioned to him that people had expressed an interest
> in merging pre-cvs change history onto the front of our tree. That
> dropped his jaw a bit ;-)

Heh. We've had similar discussions in monotone, in the context of
"partial pull" and for pre-self-hosting monotone sources.

> I think that code is very bad at expressing intent, and good history
> partially mitigates that.

Yes, certainly, but perhaps not quite in the way you meant.=20

A developer being able to look through old history and intuit the
intent and thinking behind previous work is important, but it's
primarily a human interpretation thing.  The tool can help this
process by having that history and organising its presentation, but
that's about all.

It turns out, however, that there's real functional value in this
complete history, too.  The big change from a tools and automation
perspective is also around using (capturing and recording, or
inferring later) specific developer intent.  The formal algebra for
monotone's mark-merge algorithm is all about intent-based merging and
conflict detection (primarily for tree rearrangement and whole-file
content, rather than specific lines).

Recognising that "this change" won a conflict with "that other change"
previously, and understanding when there has been new intent expressed
vs repeatedly merging over the same previously-expressed intent, is
all-important to producing satisfying merge behaviour.  Hiding
divergence and merging history from the tool has serious detrimental
effects on being able to do this properly.  Finding/reconstructing
this information in cvs history, for later use in a smarter tool, is
hard - but very, very worthwhile if it can be done.

For our specific context, mail archives of source-changes contain
vital sequencing and grouping information that's not available
elsewhere - especially if we want to try and reconstruct file
deletions and additions as renames.

--
Dan.

--I/wet25DnWlSyk1C
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (NetBSD)

iD8DBQFGrrRdEAVxvV4N66cRAjBtAKCWxeRf0R+6j0CwokT1LVve+aVUCQCfagz/
+wo5MRW6R7+5AI7Z0L7FOi4=
=Ga/g
-----END PGP SIGNATURE-----

--I/wet25DnWlSyk1C--