bug-gnu-arch
[Top][All Lists]
Advanced

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

[Bug-gnu-arch] [bug #5157] library-add should not add preceding revision


From: nobody
Subject: [Bug-gnu-arch] [bug #5157] library-add should not add preceding revisions
Date: Thu, 25 Sep 2003 21:24:58 -0400
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5a) Gecko/20030922 Mozilla Firebird/0.6.1

=================== BUG #5157: LATEST MODIFICATIONS ==================
http://savannah.gnu.org/bugs/?func=detailbug&bug_id=5157&group_id=4899

Changes by: Miles Bader <address@hidden>
Date: Fri 09/26/2003 at 10:24 (Asia/Tokyo)

------------------ Additional Follow-up Comments ----------------------------
By the way, my thought was to add two more options to library-add:



  * an `--every=N' option, which would add a separate library entry for every 
patch-P, where (P % N) == 0 between the requested revision and the highest 
existing revisions



  * an `--until' option which would say basically `just add some revisions and 
stop at the requested revision, but it's not necessary to actually add the 
requested revision'



  * allow specifying a version instead of a revision, in which case it uses the 
last revision in the version, and make the argument default to the latest 
revision in the current tree (if you're in a tree)



The old behavior of library add could be had with just `tla library-add 
--every=1 REV', and a useful thing for your cron-job/hook to do might be `tla 
library-add --every=10 --until VERSION', which would make sure the library 
space was populated automatically by every 10th revision (the --until makes it 
do this nicely regardless of the revision number actually used).



BTW, remember, if you _hate_ these ideas, be sure to say so, so I don't try 
implementing it myself... :-)





=================== BUG #5157: FULL BUG SNAPSHOT ===================


Submitted by: miles                   Project: GNU arch -- a revision control 
system
Submitted on: Tue 09/09/2003 at 08:23
Category:  tla                        Severity:  5 - Major                  
Bug Group:  small feature idea        Resolution:  None                     
Status:  Open                         Release:  
address@hidden/tla--devo--1.1--patch-153
Fixed Release:                        Merge Request?:  None                 
Your Archive Name:                    Your Archive Location:                
Assigned to:  None                    

Summary:  library-add should not add preceding revisions

Original Submission:  Currently, the tla library-add subcommand recursively 
adds all preceding

revisions (until it hits a previously added library revision),

presumably depending on hard-link sharing of files to avoid excessive

disk-space consumption.



However in my experience, this doesn't work all that well in practice -- it

_does_ end up using large amounts of excessive disk-space for the preceding

revisions, and I've had to get into the habit of going back and manually

removing all the `extra' revisions it adds to get the space back.



For instance, with the sources for tla itself, which are fairly small:



 . Size of tla sources:  4.8MB



 . I had a previous library address@hidden/tla--devo--1.1--patch-127,

   and I did `tla library-add address@hidden/tla--devo--1.1--patch-153'.

   tla automatically added all the intervening revisions, for a total of 27

   revisions added.



 . The resulting increase in disk-space usage was 39.6MB, or about 1.5MB per

   revision added -- efficient per revision, but since a version can have

   hundreds of revisions, it adds up pretty quickly, especially for large

   source trees.



 . Removing all the intervening automatically-added revisions reclaimed about

   36MB, so the single revision I actually wanted took up 3.7MB (a bit

   smaller than the actual sources, presumably because it's sharing some

   space with the other revisions I added earlier).



Anyway, I think that library-add should add just the requested revision,

finding any previously added library revision, hard-link copying that tree,

and then updating the copy in-place until the desired revision is reached.



I think this is a also reasonable from a `least surprise' point of view too

-- it does exactly what the user requests, and uses resources accordingly.



If the `add all intervening revisions' behavior is desirable, it could be

requested explicitly, e.g. with an `--until' option.



Follow-up Comments
*******************

-------------------------------------------------------
Date: Fri 09/26/2003 at 10:24       By: miles
By the way, my thought was to add two more options to library-add:



  * an `--every=N' option, which would add a separate library entry for every 
patch-P, where (P % N) == 0 between the requested revision and the highest 
existing revisions



  * an `--until' option which would say basically `just add some revisions and 
stop at the requested revision, but it's not necessary to actually add the 
requested revision'



  * allow specifying a version instead of a revision, in which case it uses the 
last revision in the version, and make the argument default to the latest 
revision in the current tree (if you're in a tree)



The old behavior of library add could be had with just `tla library-add 
--every=1 REV', and a useful thing for your cron-job/hook to do might be `tla 
library-add --every=10 --until VERSION', which would make sure the library 
space was populated automatically by every 10th revision (the --until makes it 
do this nicely regardless of the revision number actually used).



BTW, remember, if you _hate_ these ideas, be sure to say so, so I don't try 
implementing it myself... :-)




CC list is empty


No files currently attached


For detailed info, follow this link:
http://savannah.gnu.org/bugs/?func=detailbug&bug_id=5157&group_id=4899

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/





reply via email to

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