Brian Behlendorf <firstname.lastname@example.org> writes:
> Good point, both of you. What kind of data do we need to keep on the
> client side, and how is that different than what CVS tracks? If there is
> no difference, or those differences are largely cosmetic, could we use the
> same client-side-state-tracking format as used by CVS? E.g., the root in
> CVS/Root, the repository in CVS/Repository, and metadata about each file
> in CVS/Entries? Of course things like version numbers would be different,
> but that's cosmetic. I'm not too worried about people accidentially using
> old CVS tools, because presumable the actual Repository string will be
> something it doesn't understand and will fail.
Curious: if you're not worried about people accidentally using old CVS
tools, then why try for backwards compatibility?
To answer your actual question: we have to keep track of a lot more
data than CVS working copies keep track of. We have to cache changes
to the tree structure until they're committed, file/dir/dirent
properties, etc. We can probably use "Root" and "Repository" files,
but even if we called some file "Entries" it would still have to hold
different data from what the old CVS Entries file holds (for example,
sticky tags and branches don't happen the same way).
Received on Sat Oct 21 14:36:06 2006