Re: [Monotone-devel] Manifest Comments

[Christof Petig]

Markus Schiltknecht schrieb:
> I've been thinking about how to store additional information for a
> revision which got imported from another VCS (i.e. as cvs_import does).
> As certs are not stored and transmitted efficiently enough, it has been
> proposed to store such information in attributes.
> 
> However, that has various drawbacks. IMO, the most annoying one is that
> such attributes are inherited by child revisions. So let's say I have a
> manifest from an imported revision, which might look something like that:
> 
> manifest_of 0acef6004d07589fa5d7ae502bc78d2d4f8990e7
> format_version "1"
> 
> dir ""
> 
>    file "fileA"
> content [56ac1c08fa5479fd57c4a5c65861c4ed3ed93ff8]
>    attr "RCS-REVISION" "1.2.1.6"
> 
> Whenever I commit a new revision, maybe into another branch, that
> revision inherits the RCS-REVISION attribute for fileA. Which is
> obviously wrong if fileA has changed. Also, this information should be
> used to allow subsequent cvs_import commands to continue from the last
> revision they imported and just add new revisions since the last import.
> 
> Thus, one would have to remove these attributes. I've been looking
> around about how to implement "vanishing attributes", which would
> disappear on a subsequent commit. But should they appear in a 'mtn
> diff'? Then a checked out revision would show lots of changes just after
> the checkout. Maybe they could silently be ignored? Anyway, implementing
> these special attributes seems quite a lot of work, after studying some
> of the code in rosters.cc.

For re-syncing the number of the last revision which is known to CVS is
quite interesting (e.g. this content is a modified revision 1.3). So I
store revision and (a part of) the sha1 sum in cvssync3.

Actually the attibute base cvssync code in nvm.cvssync.refactor is ready
and working (preliminary 'documentation' is at the end of
mtn_cvs/CVS_prot).

Actually your manifest comment is quite similar to the certificates I
used with cvssync1. I think that attributes are really a good way to
store sync information (you convinced me of that) and was quite content
with the added sha1 information (of the last synchronized revision).
Cvssync3 does not use that information, yet, though.

If I were to freely choose a mechanism which clearly indicates whether a
file is in sync I would _modify_ the release number instead of dumping
it (e.g. "1.3"->"1.3+")

> Another point is, that these comments don't necessarily apply to files,
> but often to revisions (say, a svn_import could just list the svn
> revision number there). Of course we could also add an attribute to the
> root directory, but that seems like a hack.

That hack works well in practice. And it's scaleable to cover a lot of
synchronization partners in one tree at once.

Yours
   Christof

signature.asc
Description: OpenPGP digital signature