[Top][All Lists]
[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: |
Sun, 07 Sep 2003 23:25:59 -0400 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5a) Gecko/20030831 Mozilla Firebird/0.6.1 |
=================== BUG #5112: LATEST MODIFICATIONS ==================
http://savannah.gnu.org/bugs/?func=detailbug&bug_id=5112&group_id=4899
Changes by: Miles Bader <address@hidden>
Date: Mon 09/08/2003 at 12:25 (Asia/Tokyo)
------------------ Additional Follow-up Comments ----------------------------
> 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
=================== BUG #5112: FULL BUG SNAPSHOT ===================
Submitted by: miles Project: GNU arch -- a revision control
system
Submitted on: Sun 09/07/2003 at 11:02
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: address@hidden/tla--devo--1.1--patch-29Merge 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: Mon 09/08/2003 at 12: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: Sun 09/07/2003 at 11: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/