[Top][All Lists]

[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: Sat, 08 Nov 2003 06:24:32 -0500
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5a) Gecko/20031010 Mozilla Firebird/0.6.1 StumbleUpon/1.76

=================== BUG #5157: LATEST MODIFICATIONS ==================

Changes by: Robert Collins <address@hidden>
Date: Sat 11/08/2003 at 11:24 (GMT)

            What     | Removed                   | Added
                  CC |                           | address@hidden

------------------ Additional Follow-up Comments ----------------------------
Uhm, code talks. fine grained control over library adding behaviour will be 
useful, so I don't think some experimentation will be wasted.

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

Submitted by: miles                   Project: GNU arch -- a revision control 
Submitted on: Mon 09/08/2003 at 23:23
Category:  tla                        Severity:  5 - Major                  
Bug Group:  small feature idea        Resolution:  None                     
Status:  Open                         Release:  
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: Sat 11/08/2003 at 11:24       By: robertc
Uhm, code talks. fine grained control over library adding behaviour will be 
useful, so I don't think some experimentation will be wasted.

Date: Fri 09/26/2003 at 01: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

CC Address                          | Comment
address@hidden             | 

No files currently attached

For detailed info, follow this link:

  Message sent via/by Savannah

reply via email to

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