Re: [Monotone-devel] Manifest Comments

[Christof Petig]

Markus Schiltknecht schrieb:
> [ I note that in this ML, it's not common to 'Reply To All' and thus CC
> to the sender. I'm not quite used to that, sorry. Sending to just the
> mailing list seems to be the way it works over here, right? ]

??? Personally I don't care whether I receive mails twice, CC'ing me
directly gives a higher probability of a timely answer.

> Right, there Christof Petig has written in cvs_mtn/CVS_prot, at the very
> bottom:
> 
> =========== attributes ==============
> "" "cvs:root" "cvs.gnome.org:/cvs/gnome" (Root)
> "" "cvs:module" "glade--" (?Repository)
> ["" "cvs:path" "glade--" (only if different from module)]
> "" "cvs:branch" "STABLE" (tag)
> 
> ["po" "cvs:path" "glade--/po"]
> 
> "README" "cvs:revision" "1.15"
> ["README" "cvs:keywords" "-kb" (only if different from -kk)]
> "README" "cvs:sha1" "da39a3ee5e6b4b0d3255bfef95601890afd80709"
>     (or only first 4/6 chars)
> 
> So, you are adding the sha1 hash of the *file* (as it was in CVS) as an
> attribute. (Adding only the first 4/6 chars seems to lead to problems,
> if you ask me. Or at least some overhead for rechecking...)

Overhead? I simply use a strncmp (or a c++ equivalent) to tell whether
the monotone file (which I get by its sha1 sum) is changed. The purpose
of this is to have a reasonable chance of detecting changed files
(changed in monotone, but unknown to the cvs server) to fall back to
CVS's server based merging. Usually you use monotone to merge changes,
but the CVS variant is possible, too.

With cvssync you can import (takeover) a changed CVS workspace into
monotone and continue to work from that, then push the changes back to
the original CVS server. => You can use monotone to commit to cvs when
offline.

> What is '-kb' or '-kk' supposed to mean? And "cvs:revision" does not

Keyword expansion (-kb = binary, -kk = keywords, -ko = off etc.)

> store: "1.1 > 1.2 > ... > 1.14 > 1.15" but only "1.15". I must have
> misunderstood before. I assume the cvs:root and cvs:module attributes
> get only added to the root directory. What is cvs:path supposed to

Yes, root and module are per tree. Path is the server directory (if not
equal to root/module/subdir, e.g. think about modules which can combine
and remap (files and) directories like with symbolic links)

> track? Why do you add cvs:branch? In monotone we have certs to store
> branch information.

The cvs branch name "RELEASE_2_0" is most likely different from the
monotone branch "org.gnome.cvs.gtk+.release2_0". With cvssync you can
choose the monotone branch freely.

> IMO, storing the SHA1 hash of the original file is a work around. You
> already have that hash in the manifest in the revision which equals an
> imported one. I'd vote for implementing either 'vanishing attributes' or
> 'manifest comments' or something instead of doing work arounds.

I feel that vanishing attributes and manifest comments are a hack, too.
CVS stores the timestamp to detect changed files, so I took the sha1 sum
(monotone does not record file timestamp information). Actually I don't
see enough conceptual difference between manifest comments and
certificates to warrant the work needed to implement it.

I there were self-modifying attributes (or vanishing attributes
"cvs:synced" "true") I would use them in cvssync, but not to store the
revision information itself. ... thinking ... You are right, since I
base my update/commit on the last synchronized revision, I could use
vanishing attributes, too. Sigh. It's difficult to design a working
system without having clearly visible goals.

> ( And, if you have to store an SHA1 hash (which changes very often) for
> every file, that will probably come close to using certs, in terms of
> storage used, no? Because Delta-compression won't help much for hashes.)

delta compression helps since it only takes (approx.) 30 bits per CVS
revision to store this information (6 bytes hexadecimal numbers should
gzip compress to about their entropy: 24 bits, add some overhead). This
information is only stored (and changed) once per file revision.

Yours
   Christof

signature.asc
Description: OpenPGP digital signature