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
_______________________________________________ Monotone-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/monotone-devel
