Nathaniel Smith schrieb:
Okay, I think this is on the same track as what I meant. What I was
trying to point out was that if you know just one change that happened
in a single commit -- like, dir/changed went from 1.4 to 1.5 -- then
that should be enough to identify that entire commit. (After all,
dir/changed only goes 1.4 -> 1.5 once, ever.) Basically by looking up
when that happened, noting the time/changelog/etc., and then using
that to assemble the other changes since then.
If I get you right, you propose to identify an edge by a single change
happening within it. That's indead possible.
But the process of history reconstruction is non-trivial (you need to
associate _some_ changes to different files to emulate atomicity in CVS)
and costly (you need to issue a log command for every file (even files
you don't yet know about) in the module).
So I am very glad to have all the information ready at hand before I
connect to the server. [I issue a module wide update (sending the last
known revision of every file) and then ask for the changelog and any
intermediate contents (by patches)] This nearly as bandwidth efficient
as it might get.
This should get the size down to a reasonable amount and is readable
enough to be able to verify by sight. [That's actually the reason I
refrained from reverse diffing (store the last cert in full length and
recode older ones as time-backwards-diffs)]. I have to read and process
all the certs anyway.
Hmm, that doesn't sound very scalable. Why do you have to do that?
Actually it was done to make cvs checkout and cvs update symmetrical (to
make debugging and implementation easier). I reconstruct the same
information from the revision certs that I constructed from the cvs
server on my initial import.
On the other hand I don't know how to specify which cert to retrieve
(most of the time I need the latest cvs-manifest
(map<file,revision,keyword substitution>)), so I ask the database for
all "cvs-revision" certs. [this has the nice side-effect of enabling
update into a different branch]
Christof
signature.asc
Description: OpenPGP digital signature
_______________________________________________
Monotone-devel mailing list
Monotone-devel@xxxxxxxxxx
http://lists.nongnu.org/mailman/listinfo/monotone-devel
|
| 
