Tobias Hunger schrieb: > On Monday, 30. May 2005 18:27, you wrote: > >>Unless someone comes up with a really smart idea on how to detect this >>(does list-modules give any hint (--debug output)?) I do not see how to >>work around this problem (interesting to see how cvs manages this in its >>Entries file ...) > > > No, expand-modules does not give any hint on whether the returned module is a > file or not.
But it gives a hint that the file/path is special. And the subsequent checkout tells us. > I think CVS does not care at all: It just checks out all modules and only > after the fact (when it is easy to detect whether something is a file or > directory on the local HD) the Entries file is created. CVS does a "cvs co" (the server sends all the files at once), cvs_pull does a (cvs update &) cvs log and then asks for each unknown revision of each file separately (using patches). > I do not fully grasp what you are doing in the cvs-client. Why do you need to > get the server_dir for initial checkouts at all? Can't you just set > "Directory . dir/on/server" and check out all modules one after the other? > Afterwards you should be able to figure out the local/server directory > mapping and search for deleted files from there. > > I am pretty sure there is a good reason for doing what you do that I am > missing:-) Think about not knowing anything at all about a repository and retrieving every revision of every file with the associated metadata (author, changelog, timestamp). I do not think that (besides perhaps slicing (see below)) there is a more bandwidth efficient way to get this information. [The initial module path discovery _should_ get cached, of course!] Christof Slicing: You need e.g. revision 1.17 of several files: construct Entries for the full tree, send last known revision of files which do not have a 1.17, send 1.16 for files we want to get and 1.17 for files we already know about. Then do cvs update -r1.17 . Writing this I severely doubt that this is more efficient than requesting each revision of each file separately (in fact requesting this information file wise will use _less_ memory/disk cache on the server).
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Monotone-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/monotone-devel
