monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] Please review nvm.automate_get_roster


From: Timothy Brownawell
Subject: Re: [Monotone-devel] Please review nvm.automate_get_roster
Date: Wed, 06 Oct 2010 08:09:30 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.8) Gecko/20100821 Iceowl/1.0b2 Icedove/3.1.2

On 10/04/2010 07:32 AM, Thomas Keller wrote:

Please review the above branch. The branch name has not so much in
common with the actual implementation anymore, though:

* a new file_sizes table has been added which records the size
   in bytes of individual files
* two new automate commands have been added, get_file_size returns
   a single recorded file size, get_extended_manifest_of returns
   a format similar to the current roster format, but without the
   local node ids. Additionally, the format prints out the recorded
   file size for each file node
* migration code and tests have been added, some parts of the migration
   code were refactored / expanded
* documentation and NEWS / UPGRADE was updated as well

Since I did the migration pretty late in the process, I realized that
the put_file_sizes_for_revision() method which is used during the
migration could maybe used instead of saving the individual file sizes
on commit, but then again I thought it was cleaner (and faster) to not
have to iterate over the revision object again there.

Yeah, it's probably better to figure the sizes when you already have the file data, instead of pulling it all out of the db/cache again.


+  // FIXME: could we safely drop merge revisions here since their
+  // individual file changes should be already recorded in other
+  // revisions?

They won't be for files that had to be line-merged.


+        // if we should regenerate more than just one specific cache,
+        // we regenerate them all
+        if (m->regen_type != regen_none)
+          {
+            if (regen_type == regen_none)
+              regen_type = m->regen_type;
+            else
+              regen_type = regen_all;
+          }

I wonder would it be worth it to make regen_cache_type a set of flags, so we can or together only the needed ones?
   enum regen_cache_type { regen_none = 0, regent_rosters = 1,
                           regen_heights = 2, regen_branches = 4,
                           regen_file_sizes = 8, regen_all = 15 };

   regen_type |= m->regen_type

--
Timothy

Free public monotone hosting: http://mtn-host.prjek.net



reply via email to

[Prev in Thread] Current Thread [Next in Thread]