Re: [Monotone-devel] monotone.cvssync: Invariant failure

[Christof Petig]

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