[RFC] Commit Builder restructuring (Re: [RFC] letting the commit builder assign the file ids)

Aaron Bentley aaron.bentley at utoronto.ca
Thu Dec 21 16:00:16 GMT 2006


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

Jelmer Vernooij wrote:
> On Thu, 2006-12-21 at 09:29 -0500, Aaron Bentley wrote:
> 
>>Jelmer Vernooij wrote:
>>
>>>Thoughts?
>>
>>Could you explain why the bzr-svn generates new file ids at commit time?
>> Why doesn't it do that when you import a branch from bzr?
> 
> Well, that's when it usually generates file ids.

Eh?  You mean it generates new file ids on import?  I thought that
bzr-svn was able to roundtrip bzr data.

If it can, then it should be able to use that mechanism instead of
generating new file ids.

If it can't, we should be aiming at that instead.

> foo                         foo--20061221151143-50yaxntdektqvtue-1
> $ bzr commit
> ^^ bzr-svn will assign a different file-id to "foo",

Why?  SVN doesn't have file-ids, so it can't be intrisic to SVN.  It
sounds as if bzr-svn is assigning new file-ids for no good reason.

>>CommitBuilder.set_working_tree(wt)
> 
> ^^ wt would be any Tree, not necessarily a WorkingTree ? I think it
> should be possible to do a commit without a working tree.

> And a sideeffect of record_change() could be that the file id of one
> entries in CommitBuilder.working_tree would change?

I find these inconsistent.

I agree that it would be nice if wt didn't actually have to be a working
tree.  So it could, for example, be a RevisionTree.

But if it's a RevisionTree, it's supposed to be immutable, so it's wrong
to change the file ids of its entries.

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

iD8DBQFFiq+Q0F+nu1YWqI0RAp5rAJ9tEl+oBJ7NkHdLxlO+uZAT4dhh+wCfeigs
ZpXk+mVuqGAZ28XAj8FOgWs=
=bmjI
-----END PGP SIGNATURE-----




More information about the bazaar mailing list