Are svn properties in bzr-svn important?

[Jelmer Vernooij]

On Thu, 2007-07-12 at 10:16 -0400, Aaron Bentley wrote:
> Jelmer Vernooij wrote:
> > On Thu, 2007-07-12 at 09:37 -0400, Aaron Bentley wrote:
> >> Jelmer Vernooij wrote:
> > In the current scheme, bzr:merge contains anything that's ever been
> > merged. When looking for the merged revisions, I look for changes to
> > bzr:merge. 
> > 
> > If I would keep this property limited to one line, that would have the
> > following disadvantages:
> > 
> >  * get_ancestry() would significantly slower. This should be acceptable
> > I think
> You could cache this data.  Significantly, you can cache it on the
> client side.  But you may even be able to cache it server-side.

> Say you create a fake revision 6, with an "ancestry" property.  Since
> revision properties in svn are mutable, you can use that property of
> revision 6 to track data about all revisions in the system.
> 
> Also, I'll remind you that as part of the performance drive, we are
> working on supporting operations using partial histories.  So
> get_ancestry should ultimately never be used.  Only get_parents.
Right, I think get_ancestry() is not a big reason for the current reason of this format. Having 
the contents make sense is more important though. Always truncating
seems like a bit of a hack to me. These are file properties, not
revision properties (which aren't used because they require additional
repository configuration /and/ are modifiable later).

> >  * Looking at bzr:merge for a revision X will contain one line Y and
> > suggest that Y was merged in X, whereas it was perhaps actually merged
> > in X-2.
> Why wouldn't it be marked in X-2, then?
The file property would be set in X-2, but as they mean nothing to
Subversion users, the property would keep the same value in X-1 and X.

> > I could use Subversion revision properties for bzr:merge, but they can
> > be configured to be modifiable afterwards and need to be enabled in the
> > repository configuration.
> 
> Oh, are these file properties?
Yes, they are file properties set on the root of a branch. They are set
during commit.

Cheers,

Jelmer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20070712/972350ba/attachment.pgp