Nathaniel Smith schrieb: > On Sun, Aug 27, 2006 at 12:07:33AM +0200, Christof Petig wrote: >> The main reason for me to use a special file format is to have the >> information in one place (which also applies to attributes) and to base >> some logic upon whether this file was changed since the last revision. >> >> Yeah file attributes appeal to me, too (on second thought) (but that >> does not solve the "push can't change this information" problem). >> >> Do file attributes scale well enough? (since they are part of the >> revision information, I would need three per file ...) > > What do you use the 3 for?
rcs-revision, keyword expansion, and possibly unchanged/original_id/whatever_you_call_it. We might put all three into one attribute. And I would need to store server address and module and directory structure somewhere. I was glad to have all of this in one place (one single file). > They are pretty efficient -- most importantly, revisions only describe > changes in attributes, and they are stored inside the roster, which is > already delta-compressed as a whole. I can't think of any reason why > this would be noticeably less efficient than putting the same > information in a file. Using one (combined instead of three) attribute would _double_ the lines in the roster, using a single file only adds one. [Using three would quadruple the lines] > >> I wrote a command to retrieve the whole sync information per revision. > > The manifest includes all file attributes; you can simply read them > all off of there. I see (mtn automate get_manifest_of). >> And I also had svn on my mind when I designed that feature. > > Not sure what you mean here. Surely for svn synchronization, you only > need to know svn's whole-repo version number, plus where in the svn > namespace this mtn branch belongs? (I.e., "this mtn revision > corresponds to the /branches/foo/ subtree of svn revision 1234".) That's right. Svn would only need a single number ... unless you start to take changed files into account (IIRC svn stores an unchanged copy of each file in the workspace). So I designed a mechanism which would work the same for the simple case (one number) and the complex case (a number per file). >> My feeling is that I follow my chosen way further and see where I get >> to. Changing the storage form is not that difficult. > > Nod. mtn_cvs pull is finished and the tests are ok, I'm working on push functionality. (Porting the program from linking to monotone to using the automate interface was a good step but there is still some code which directly uses monotone internals - e.g. rosters, certs) Christof
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel