path tokens

[Aaron Bentley]

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

Robert Collins wrote:
> I'd like us to consider overhauling the concept of fileids. I think
> fileids serve an important purpose, in letting us unambigously talk
> about a versioned path in multiple trees when it has been
> renamed/deleted/etc. But as currently defined they restrict us nearly as
> much as they simplify our code for merge etc.
> 
> So here are a few ideas that I have about the shape of a new tool, which
> I'll call path tokens, to avoid confusion with file ids [a better name
> is welcome].

"path" is probably not going to work, just because the obvious
interpretation is an association of paths (not the contents currently at
those paths) with tokens.

> Parallel imports: There are many cases where parallel imports occur.
> These imports make it difficult to really work in a decentralised
> manner

I think that addressing parallel imports well demands more than
addressing the file-id issue.  It would also be able to match up the
revisions created by parallel imports.

> Copies also make sense for some user
> operations, like splitting a files contents, or take a file like
> 'COPYING' that does not change often and putting it into other locations
> or trees.

It's not clear to me that we should use the same primitive to represent
both those operations.  The output of a split is two files with no
common contents that are both related to the base file.  The output of a
copy is two files that have identical contents to the base file.  In the
first case, applying a merge from a pre-split tree should apply each
change only once.  But in the second case, a merge from a pre-copy tree
the changes would be applied twice: once to each file.

Finally, it's not at all clear that anyone really wants COPYING to be
treated as the same everywhere.  Because if COPYING changes, that would
mean that everyone in a project had agreed to change the license.  If
you have two copies of COPYING, you probably have two sub-projects in a
tree.  So it's quite conceivable that one sub-project might change their
license, while the other did not.

> Two versioned paths become one: This is mostly covered in my text about
> parallel imports. While not quite the same thing they are closely
> related.

Being the inverse of copies, there are many commands (e.g. merge,
revert) that would need to handle this, just because of the copy support.

> To be clear: I dont intend this email to provoke immediate discussion on
> 'file copies must do X' or 'must NOT do X', rather on 'Yes, we should
> support file copies IF we can design good semantics' vs 'No, even if we
> can design good semantics for file copies, we must not support them'.

My objection has always been that there are no sane semantics for copy.
 Prove me wrong, and I'll be happy.

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

iD8DBQFF+VDk0F+nu1YWqI0RAt1/AJ98mTQKmaP2nUA4IcGIFpw/5+iToACeNUOR
y+EH27Wi1Myzvh18PVypj78=
=GSIK
-----END PGP SIGNATURE-----