[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 ==================
http://savannah.gnu.org/bugs/?func=detailbug&bug_id=5157&group_id=4899
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
system
Submitted on: Mon 09/08/2003 at 23: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: 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:
http://savannah.gnu.org/bugs/?func=detailbug&bug_id=5157&group_id=4899
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Bug-gnu-arch] [bug #5157] library-add should not add preceding revisions,
nobody <=