Re: [Monotone-devel] Manifest Comments

[Christof Petig]

Hi Markus,

Markus Schiltknecht schrieb:
> Christof Petig wrote:
>> 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.
> 
> Of what sha1 sum? Where do you store that? You don't store *that* in the
> file attributes, do you?

I do ... (but I truncate the sha1 to six letters (arbitrary))

$ mtn -d test.db automate get_sync_info ef54d60...c7920b cvs

  set ""
 attr "cvs:module"
value "test"

  set ""
 attr "cvs:root"
value "vesta.petig-baender.de:/.../pull_combined/cvs-repository"

  set "A"
 attr "cvs:revision"
value "1.3"

  set "A"
 attr "cvs:sha1"
value "fccdef"

This way I can easily handle:
- sharing attributes with an upcoming cvs_import (cvs:revision),
cvs:sha1 is optional
- detecting modified files (at least as reliably as cvs does with it's
timestamps)
- flagging files unconditionally as modified: 'cvs:sha1=X' (big letter
X) and unmodified (removing cvs:sha1)

Adding only missing attributes to newer releases. Perhaps "A" "cvs:info"
"1.3,-kk,fccdef" would be more terse but since it's delta encoded and
gzipped I decided to use the more user friendly splitted variant (e.g.
mtn attr set A cvs:keywords -- -kb )

>> 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).
> 
> I'll check that documentation out...

look at the last lines in that file (my notes on understanding the CVS
protocol are not that interesting)

>> 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)
> 
> Was that really me? :-)

... you at least asked why I did not use attributes ...

>> 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+")
> 
> Hm.. yes, that's a very nice idea. Using delta compression, this won't
> cost more than changing it.

attribute changes like this are not delta encoded, but still gzip
compressed.

> What I fear is, that this might become a huge attribute value one day
> (read: when importing large repositories).

read my arrow as "1.3" changes to "1.3+" once the file is modified.

> You are circumventing my major point against file attributes (which is
> that they are inherited by subsequent commits and shown in diffs) by
> saying you don't store *the* RCS release number of the file, but the
> complete history. Relabeling the field to mean: the file is based on
> these RCS versions.

> Plus: that might fit well for CVS, but how about subversion or git. Do
> you really want to store:
> 
> "r1 > r2 > r3 > r4 > r5 > r5 .... r3267 > r3268 > r3269" in a file
> attribute value for the root directory? That seems messy to me. And it
> would show up in a diff.

I think this is a misunderstanding. But I clearly need the last synced
revision and whether it is modified for cvssync.

Yours
   Christof

(currently implementing mtn->cvs export and cvssync 0.24->0.31 migration)

signature.asc
Description: OpenPGP digital signature