[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Feature request/ideas
From: |
Derek Price |
Subject: |
Re: Feature request/ideas |
Date: |
Thu, 03 Mar 2005 11:50:05 -0500 |
User-agent: |
Mozilla Thunderbird 1.0 (Windows/20041206) |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Mark D. Baushke wrote:
| Derek Price <dprice@cvshome.org> writes:
|
|> Derek Price wrote:
|
|>> |> | So probably the expression used should connote this. After
|>> some |> | consideration, I would vote for '.origin' here. I
|>> disagree |> with | being meaningless. I often export a project
|>> state into a |> local | repository, work on it, and when I'm
|>> done, move the files |> back to | the remote repository's
|>> sandbox. During local |> development I often | want to compare
|>> to the initial version of a |> file, and using a | single tag
|>> for this is just easy. Granted |> there are other ways to |
|>> achieve this, but they're not as easy |> to handle. |> |>
|>> That's fine for 1.1, but how does this help you for a branch?
|>> |> You might want to diff against the root, but it doesn't make
|>> much |> sense to care about the first revision on the branch. |
|>> | | Good point. What about resolving '.origin' to the very
|>> first | revision of the mainline?
|>>
|>>
|>> I don't have any reason to object to that.
|
|
|> On further consideration, why doesn't -r1.1 suffice for what you
|> want to do?
|
|
| Possibly for handling the following conditions...
|
| - cvs add foo && cvs commit -mnew foo && echo newstuff >>foo \ &&
| cvs commit -mupdate foo && cvs admin -o1.1 foo
|
| .origin == 1.2 after this operation
|
| - cvs add foo && cvs commit -mnew -r2.1 foo
|
| .origin == 2.1
Well, yes, but -r1.2 or -r2.1 would suffice in these cases, though I
will grant you have to know what revision to use. I would hazard that
there is either a -r<rev> revision that can be specified here across
multiple files or that the result of a multi-file .origin will likely
be meaningless anyhow.
In the specific example Frank specified, also, -r1.1 should always work.
| - cvs tag -b foo-branch && cvs update -rfoo-branch && cvs add foo \
| && cvs commit -mnew foo
|
| In this case, is .origin == 1.1 (dead) or is it not found?
I have no idea. I think for most use cases either will have the same
result. For cvs up -r.origin foo, where foo has no origin, I see
little difference between an error message that says .origin not found
and a silent checkout of nothing (the dead revision), but maybe
someone else has a reason to prefer one over the other.
| - cvs tag -b foo-branch && cvs update -rfoo-branch && cvs add foo \
| && cvs commit -mnew foo && cvs update -A && cvs up -jfoo-branch \
| && cvs commit -mmerge foo
|
| .origin == 1.2
I don't think so. This should be consistent with the answer to your
previous question. If the -r.origin with only a dead revision returns
the dead revision, then this .origin should also return it. If
- -r.origin with only a dead revision returns no revision, then this
should return 1.2, as you specify.
| I have no objections to .origin being used for the very first
| revision of the mainline.
It's not that big a deal, really, but I would like to hear a use case
that can't be satisified with a simple revision selection or hear a
person or two declare strongly that they prefer the convenience of an
.origin that may sometimes be meaningless to an additional call or two
to `cvs log'.
Regards,
Derek
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCJ0A8LD1OTBfyMaQRAsjPAKDAJODmsV7MYXc+LJ/eQ6wI9XDPmgCg257L
Ntyx7xsNC6o6XAr15UT/Yrw=
=UzxB
-----END PGP SIGNATURE-----
- Re: Feature request/ideas, (continued)
- Re: Feature request/ideas, Mark D. Baushke, 2005/03/03
- Re: Feature request/ideas, Larry Jones, 2005/03/03
- Re: Feature request/ideas, Mark D. Baushke, 2005/03/03
- Re: Feature request/ideas, Derek Price, 2005/03/03
- Re: Feature request/ideas, Mark D. Baushke, 2005/03/03
- Re: Feature request/ideas, Derek Price, 2005/03/03
- Re: Feature request/ideas, Mark D. Baushke, 2005/03/03
- Re: Feature request/ideas, Derek Price, 2005/03/03
- Re: Feature request/ideas, Derek Price, 2005/03/04
- Re: Feature request/ideas, Frank Hemer, 2005/03/05
- Re: Feature request/ideas,
Derek Price <=
Re: Feature request/ideas, Larry Jones, 2005/03/02
Re: Feature request/ideas, Mark D. Baushke, 2005/03/02
Re: Feature request/ideas, Frank Hemer, 2005/03/08