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

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

[Bug-gnu-arch] [bug #5112] Rework replay command-line processing


From: nobody
Subject: [Bug-gnu-arch] [bug #5112] Rework replay command-line processing
Date: Tue, 23 Sep 2003 16:42:38 -0400
User-agent: Mozilla/4.76 [en] (X11; U; FreeBSD 3.0-RELEASE i386)

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

Changes by: Tom Lord <address@hidden>
Date: Tue 09/23/2003 at 13:42 (US/Pacific)

            What     | Removed                   | Added
---------------------------------------------------------------------------
          Resolution | None                      | Fixed
              Status | Open                      | Closed
       Fixed Release | address@hidden/tla--devo--1.1--patch-29 | tla-1.1pre6, 
address@hidden/tla--devo--1.1--patch-174




=================== BUG #5112: FULL BUG SNAPSHOT ===================


Submitted by: miles                   Project: GNU arch -- a revision control 
system
Submitted on: Sat 09/06/2003 at 19:02
Category:  tla                        Severity:  5 - Major                  
Bug Group:  small feature idea        Resolution:  Fixed                    
Status:  Closed                       Release:  
address@hidden/tla--devo--1.1--patch-153
Fixed Release:  tla-1.1pre6, address@hidden/tla--devo--1.1--patch-174Merge 
Request?:  yes -- merge from my archive
Your Archive Name:  address@hidden Archive Location:  
http://arch.linuxguru.net/~miles/address@hidden
Assigned to:  None                    

Summary:  Rework replay command-line processing

Original Submission:  (1) Remove the --exact option.  Now if you specify a 
revision, it will apply (or reverse) exactly that revision, and if you specify 
a version it will apply missing/new patches in that version.



    I think this new usage is far more natural; --exact always seemed 
superfluous (`I specified a revision, why can't it know to just apply that 
revision?!?'), sort of like --files did.



(2) Allow multiple version/revision arguments.  I've often wanted to replay 
multiple changesets at once, and it's a minor convenience to be able to give 
them all on the command line.  It's probably less useful for version arguments, 
but I implemented that too for    consistency's sake.



(3) Do more rigorous argument checking, and hopefully improve the error 
messages a bit.



(4) Eliminate all the duplicate code between the `missing' and `new' cases.



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

-------------------------------------------------------
Date: Sun 09/07/2003 at 20:25       By: miles
> Formerly,

> 

>   tla replay REVISION

> 

> would replay all revisions from the one just past the most recent

> revision my tree already has, up to REVISION.



Did it really do that?!?  The docstring doesn't mention it, and the

code didn't _seem_ to do anything like that:



   In the old code, the default (without extra options) was always

   arch_replay_op_missing, and that just did:



       version = arch_parse_package_name (arch_ret_non_archive, 0, src_spec);

       revisions = arch_whats_missing (tree_root, arch, version);

       ... replay revisions ...



   In arch_whats_missing, I see this:



       has = arch_log_ls (tree_root, arch->name, version, 0);

       needs = arch_archive_revisions (arch, version, 0);

       answer = rel_join (2, rel_join_output (2,0, -1), 0, 0, has, needs);



   Does `arch_archive_revisions' do something magic along those lines?

   I got a bit lost trying to trace how things happen below that, but as

   far as I can see it just ignores any patch-level specified.



The one feature I _did_ remove was that if you specified `--exact VERSION'

it would replay just the _last_ patch-level in VERSION; this was

undocumented, and didn't seem particularly useful (maybe the intent was

to use it in conjunction with --reverse?)



> How do I do this after these changes?



You can't.  I think the cleanest way to do this sort of thing would be

an `--until REVISION' option.



Then you could do `tla replay --until REVISION' which seems very

intuitive.



> The `update' command invokes the `replay' command.   

> 

> Does that still work correctly?



As far as I can tell.  update just uses `tla replay --new VERSION' and

my change shouldn't effect that usage; update explicitly makes sure that

VERSION doesn't contain a patch-level:



   version = arch_parse_package_name (arch_ret_package_version, 0, rvsnspec);

   ...

   arch_call_cmd (arch_cmd_replay, argv[0], "--new", "-A", archive, "--dir", 
dest, version, 0);



-Miles



-------------------------------------------------------
Date: Sat 09/06/2003 at 19:16       By: tomlord
Formerly,



  tla replay REVISION



would replay all revisions from the one just past the

most recent revision my tree already has, up to REVISION.

How do I do this after these changes?



The `update' command invokes the `replay' command.   

Does that still work correctly?



-t






CC list is empty


No files currently attached


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

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





reply via email to

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