[RFC] Tracking file copies

[Jan Hudec]

On Mon, Jun 19, 2006 at 19:13:55 +0200, Jelmer Vernooij wrote:
> On Mon, 2006-06-19 at 18:43 +0200, Johan Rydberg wrote:
> > John Arbash Meinel <john at arbash-meinel.com> writes:
> > 
> > >> I am mainly interested in this information as metadata - so it can be
> > >> imported from and exported to other version control systems. It might
> > >> also help in terms of storage for some storage backends (in the case of
> > >> weaves, keep both files in one weave?).
> > >
> > > [...]
> > > Are you wanting to create a new separate file
> > > (.bzr/repository/file-id-copies.knit), or just as a revision property,
> > > or just as a record in the knit index, or ...
> > Having a separate versioned file for it would probably be the
> > simplest, storage wise.  But we would have to extend our interfaces to
> > support it, which I feel could become quite ugly.
> Would putting it into the InventoryEntry help? That's the place that
> makes the most sense to me and it won't complicate the interface. Some
> formats could simply not support tracking file copies.

There are many proposals pending that will need to put things into
InventoryEntry, so creating a generalizable way to add them would be
good. It would be pretty involved as well, since it needs new inventory
format and therefore new repository and workingtree formats.

Lately I had the idea, that instead of adding attributes to inventory
entries, we could add special InventoryEntry objects. Ie. there would be
a subclass of InventoryEntry with kind 'copied-from' (or whatever; other
kinds would be 'executable', 'ignore', 'keywords', 'line-endings'.
etc...; maybe they would be fewer 'kinds' (subtypes) and differentiated
by special (they would have to be non-strings or contain \0 or something
like that) names). Instances of these would be childen of entries they
describe. They could be stored in inventory only (as symlinks are) or
have their own versionedfile, depeding on the particular property kind.

Certainly what I would *NOT* want is generic metadata like subversion
has and using them for our data. Each property would have to have a
class describing it's behaviour.

> > We could have had versioned file ids; where a file is identified by a
> > <file-id, version> tuple.  If you copy the file, the version is
> > increased.  But that would make merge hard as well (merge two
> > revisions that both have copied the same file, but for different
> > reasons).  And it would require extensive surgery to our code.
> I wouldn't dare suggest that. (-:
> 
> Cheers,
> 
> Jelmer
> -- 
> Jelmer Vernooij <jelmer at samba.org> - http://samba.org/~jelmer/


-- 
						 Jan 'Bulb' Hudec <bulb at ucw.cz>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060620/8847aba2/attachment.pgp