[Top][All Lists]

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

Update to a different file (was Re: Update)

From: Eric Siegerman
Subject: Update to a different file (was Re: Update)
Date: Tue, 24 Jul 2001 20:42:15 -0400
User-agent: Mutt/1.2.5i

On Tue, Jul 24, 2001 at 03:45:47PM -0700, Eugene Yi (InfoSpace Inc) wrote:
> I want to know if there's a way to capture a copy of an already checked out
> file from the repository.

In other words, check out a copy of foo.c into a file called foo.c.copy?

> I guess I can do "cvs update -p <filename> > <some file path>"
> in command prompt

That's the standard way to do it.

> but is there any other way using a
> legit cvs command?

Nope.  Might be nice, but it'd clutter up the interface a bit.

I'm generally against reinventing the wheel, which is what adding
such an option to CVS would be doing, but in this case I rather
like the idea.

The usual single-file update is of course:
        cvs update foo.c
To get the results into a different file, you do:
        cvs update -p foo.c >foo.c.copy

To accomplish one change in the results -- putting the file in a
different place -- I expect to make one change in the recipe.
CVS requires me to make *two* changes -- "-p" and ">foo.c.copy".

Because of the one-change expectation, and because ">file"
meaning "put it there" is so instinctive to a Unix user, I often
forget the "-p" -- indeed, I did so when first typing the above
example, even though it's precisely what I'm talking about.  The
results of this error are an empty foo.c.copy and potentially a
clobbered foo.c.

(Yes, I understand why the "-p" is necessary, and why it makes
sense from CVS's point of view; I submit that from the USER's
point of view, it does NOT make sense.)

To make matters worse, these two recipe changes are separated by
the filename (foo.c) in the usual form of the command.  Sure, one
could type:
        cvs update -p >foo.c.copy foo.c
But putting the redirection in the middle of the arguments is too
bizarre to be any improvement.  It invites thinking of "foo.c.copy"
as an argument to "-p", and thus forgetting the ">":
        cvs update -pfoo.c.copy foo.c

So, we have an error that is (a) easy to make, because one's
natural expectations lead to it, and (b) potentially unpleasant.
This is a good reason to invent an alternative.

Note that one special case of the above situation has recently
been dealt with:  update's -C option is a better version of:
        cvs update -p foo.c >foo.c
It would be nice to provide something for the general case, i.e.
where the file names aren't the same.


|  | /\
|-_|/  >   Eric Siegerman, Toronto, Ont.        address@hidden
|  |  /
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea.
        - RFC 1925 (quoting an unnamed source)

reply via email to

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