path tokens

[Robert Collins]

On Thu, 2007-03-15 at 09:57 -0400, Aaron Bentley wrote:
> -----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.

Yes. file is wrong though, because directories are not files (at least,
not for folk that dont understand how they are implemented down in the
guts). I'd love a better name.

> > 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.

One way of doing that is creating new revisions that merge both imports.
I.e. if you have A and A' which was a parallel import, create A'' which
has A and A' as parents, and a revision-property to indicate that it
does this. That said, I think this can be built later - doing
revision-mapping without solving the 'these files are different to the
core of the system' issue is pointless; once the files can mapped to
each other, we can look at mapping revisions around.

> > 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.

I'd like to take these points to the discussion about what copying
semantics should be.

> > 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.

Yes.

> > 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.

Ok, so can I read this email as 'agreed in principle *pending agreement
on sane copy/combine semantics*' ?

-Rob

-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20070316/a08dbeae/attachment.pgp