On Tue, Oct 18, 2005 at 04:11:39PM +0900, Stephen J. Turnbull wrote: > >>>>> "David" == David Roundy <[EMAIL PROTECTED]> writes: > > David> On Fri, Oct 14, 2005 at 07:59:48PM +0930, Jonathon Mah wrote: > > > The current usage for this command is: > > Usage: darcs put [OPTION]... <REPOSITORY> > > > From that it is not clear that <REPOSITORY> is the location of a > > _new_ repository. Something like <NEW REPOSITORY> would make it more > > evident. > > David> Done. > > It would be nice if this were consistent throughout. In my notes to > myself, as well as in naming arguments in scripts, etc, I consistently > use "repo[sitory]" for an existing repository and "branch" for the new > repository. When both exist, it's "local" (what I've been hacking on > most recently) and "remote" (archival or mainline). I tried "source" > and "target" (eg for push and pull), but that didn't work so well for > me.
Indeed. I liked the verbose <NEW REPOSITORY>. For push and pull/send <SOURCE REPO> and <TARGET REPO> seem good to me (or full <SOURCE REPOSITORY> if it seems likely to fit on the line). I'm not sure what other possibilities there are, but if you take a look and make a proposal for a consistent terminology, I'll look it over and let you know whether I'd approve a patch making the change (before you go to the trouble of looking at each and every command). > This works for me, although I hesitate to recommend adoption by the > project because others might put a different spin on words like > "branch" and "local". I agree. I'd avoid "remote" since no darcs command really requires that a repository be "remote", and terminology like "branch" are really descriptive of use rather than function. "local" seems okay, if the repo really needs to be local. > If a consensus appears in favor of some terminology, I'll make time to > review the commands and cons up a patch. As I say, if you propose a (hopefully conservative--or agreeing with a subset of existing practice) terminology, I'll let you know if I agree with it, and then you can go ahead and do this. > I'd also like more consistency in the object-specification options. > --patch works for everything I used, but IIRC the official names are > longer and vary from command to command. Similarly with --repo vs > --repo-name, etc. (I realize that last seems to be a distinction of > existing vs. new, but that's too fine for me to remember at use time.) The idea between --patch and --patches is to distinguish whether the match will match a single patch or if it will match all patches that match. I think this is reasonable, but should perhaps be documented. --repo vs --repo-name is like --patch vs --patch-name, the -name means you're giving a new name, not a regexp that will match an existing name. At least that's what it's intended to mean... if it doesn't work that way, we should fix it. I don't like the same command having different behaviors. For example, if you had just one repository, you might want to stick in your ~/.darcs/defaults "ALL --repo /the/only/repo" so you could whatsnew from whereever you are. But it would be dissapointing if this would mean that you always had to specify a second argument to get to avoid getting the error message darcs failed: Directory or file named '/the/only/repo' already exists. This is a rather contrived example, but I just don't like the idea of the same flag name having different behavior for different commands. Actually, removing the --repo-name flag from get entirely wouldn't be a bad idea. It's redundant with the more intuitive method of giving a second argument to get. I never use it, and wouldn't encourage anyone else to do so... It dates from before get accepted a second argument. -- David Roundy http://www.darcs.net _______________________________________________ darcs-users mailing list [email protected] http://www.abridgegame.org/mailman/listinfo/darcs-users
