monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] Re: big repositories inconveniences (partial pull?)


From: Daniel Carosone
Subject: Re: [Monotone-devel] Re: big repositories inconveniences (partial pull?)
Date: Mon, 28 Aug 2006 11:24:09 +1000
User-agent: Mutt/1.5.13 (2006-08-11)

On Sun, Aug 27, 2006 at 03:10:45AM -0700, Nathaniel Smith wrote:
> As Lapo pointed out, I think you might have misunderstood... I didn't
> mean to attach this information to file_id's.  I meant to attach it
> to files in the tree, using the attr mechanism:
>   http://venge.net/monotone/docs/File-Attributes.html
> Such attrs are stored and transferred reasonably efficiently,

It seems like they're pretty close to right for what's wanted..  what
would help is a kind of attribute that automatically was reset or
removed when the file content was later changed (ie, via a local
commit in monotone that hadn't yet been synced).

This would prevent changed files from carrying stale attributes
claiming equivalence to specific CVS revisions.  Alternately, the file
hash could be asserted within the attribute, and the attribute would
then describe the original CVS version whence the current file was
derived, if there had been a change.  You could probably infer this
from the DAG history without the extra storage if you were careful:
the first revision where a particular attribute value was set, which
will conveniently also be a marked revision for the merger.

The corresponding implication is that when monotone changes are pushed
back into CVS via a sync, a new monotone revision needs to be
committed with the attribute changes. This sort of seems like a
feature to me.

--
Dan.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]