[Top][All Lists]

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

Re: [Gnu-arch-users] [MERGE REQUEST] unify various commands around arch_

From: Aaron Bentley
Subject: Re: [Gnu-arch-users] [MERGE REQUEST] unify various commands around arch_fqvsn_from_tree_and_input
Date: Wed, 19 May 2004 23:22:56 -0400
User-agent: Mozilla Thunderbird 0.5 (X11/20040306)

Colin Walters wrote:
Interesting.  Well I think we're actually solving somewhat different but
related problems.  Notice that we actually patched different sets of
commands (you patched tag and sync-tree, I patched delta, get-changeset,
and undo).

I think get-changeset is an arch_determine_revision candidate, not a fqvsn_from_tree_and_input candidate, because it's not a project tree command, and not necessarily run in a project tree. If you look at get, you'll find it uses the archive-latest revision, and I think get-changeset would be analogous.

It would also be nice to stick an arch_check_for in there, to handle the case where the user-supplied revision/version doesn't exist.

Let me describe my function arch_fqvsn_from_tree_and_input.  It's meant
to take any sort of user input (from a fully-qualified revision like
address@hidden/project--main--0--patch-32) to bare patchlevels like
patch-32. If the input is already fully-qualified, just return that.

Err, are you handling the case where you just get a package-version and you have to determine the revision from the logs? (see 'tla changes' for an example)

The key difference with what arch_fqvsn_from_tree_and_input does is that
it uses the current tree version to disambiguate.

Okay, so little risk of us making conflicting changes. (Though I've patched delta too...)

Now I'm pretty sure I'm on the right track with this thing because most
of my changesets consist of *deleting* code and replacing it with this,
with no loss in functionality or semantics, etc.

Just be careful not to change functions that already use the archive-latest revision!

With the sole
exception of delta, and I'm about to fix that now.

Perhaps a soft_errors parameter would do the trick.

Your function doesn't touch the tree version at all - instead it looks
at the default archive.  So I think both of them make sense.  Probably

Yeah, my function was basically a rip of sync-tree's functionality. But it only uses the default archive if there's no archive name provided by the user.


reply via email to

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