[RFC] Concept of unique line ids

[Aaron Bentley]

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

Alexander Belchenko wrote:
> I think that concept of unique line ids is very important
> for cherrypicking support, for detecting moving of lines
> inside one file or between files.

Yes, I think the concept of line identity would allow really powerful
merge capabilities.  But at the same time, doing it efficiently would
probably require major changes to our architecture.  So for me, this is
a long-term project.

> Diff for original sources is really small, but merge
> in bzr produce HUGE conflict. Using merge --diff3
> give me much better result (IMO, because patience diff
> want to find max difference, while unidiff is not).

Are you using --reprocess?  There shouldn't be much difference between
the --merge3 --reprocess and the --diff3 output.

> But actually I expect that merge will pick only new
> changes and apply them to corresponding part of my sources.
> But bzr unable to help me here.
> With unique line ids IMO this should be straightforward:
> apply changes only to lines with specific line ids.

We part ways here, because I wouldn't expect a line to maintain its ID
if its content is changed.  I don't think that's really manageable.

> May be I need thing that Aaron called annotation-based merge?
> I don't understand merge internals deep enough, so
> I'm not sure here. Annotation-based merge is not implemented yet,
> right? Or I again missed something?

It is implemented as --merge-type weave.  It's referred to as knit
merge, but even that isn't really accurate, because it doesn't require
knits, just annotations.  So I've been calling it annotate merge.  Sorry
for any confusion.

> Where to read about annotation-based merge to understand
> is this the same or I on wrong way?

http://bazaar-vcs.org/KnitMerge

I would propose using line identity for a form of edge-based merging,
like Precise Codeville Merge:
http://revctrl.org/PreciseCodevilleMerge

To support movement of lines between files, the internal representation
would be a graph containing the entire content of the tree.  There would
be special edges at the beginning and end of files.  For performance
reasons, we'd need a way to work with only the relevant subset of the graph.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG3ZWK0F+nu1YWqI0RArIyAJ9e15IdZR7d7TF3pHCTecVM6qnuUwCeNPti
dKXJQCYAny5mUDmwzALQQcU=
=F1w5
-----END PGP SIGNATURE-----