On Monday, March 6, Michael Gersten wrote:
>
> Toby, do you program in assembly? I don't anymore.
If the need presents itself, yes. If using a couple assembly routines,
which are already written, will easily solve the problem, yes.
> I'm not trying to be mean or anything. I'm trying to point out
> something here.
Please do so.
> I drive automatics, not sticks.
> I write in high level languages, not assembly.
I drive sticks, I drive to live, not commute. I code mainly in C, and
perl. But I also code in assembly when the time/space tradeoff warrants.
I string "unix commands" as needed, sometimes piping 5-6 commands, one
after the other. If things warrant, I write a perl/C program/script to
get the job done in a faster, more efficient manner...
> I like the windows find tool that combines find, xargs, and grep in
> one box. Yes, it's limited, but it often works faster than trying to
> get the correct command typed in. And, it's more of what I think of.
I'm sorry to hear that. What you are telling me, is that you like to be
limited by convenience...
> I don't want to be told "Here's a list of commands you can use to get
> this done". I want one command that does it.
Then I urge you to go somewhere else. I'm telling you an easy, straight-
forward way of doing it. It may not be an "automatic", but I'm telling you
that if you put it in 1st, let out the clutch, and step on the gas, you will
have accomplished all you wished, in the time it took to explain to me that
you really were looking to have an "automatic"...
> I don't want to have to remember a list of steps, and worry about "did
> I make a mistake anywhere?".
Welcome to high-level languages. The ones you like. Make a script, put the
sequence into a shell alias. Be creative...
> Yes, there is the ability to do this in CVS. As you said,
> > Cripes, use "cvs diff" to give you a diff of your changes, checkout
> > a new sandbox (or revert your old one), add the branch, apply the
> > diffs (using patch), commit.
> So I need to use diff, a temp file, a new checkout, and patch. Why not
> have it all in one command?
As I've said above, put it in a script, ignore it, I really don't care at
this point. I'm giving you a viable way of doing what you need to do. If
that does not meet your needs, feel free to ignore it. I may have been a
bit abrasive at pointing it out, but I believe that I've given a solution
that does not require "yet another feature, knob, etc"...
> *** You don't make something easy to use by putting a GUI on it.
> *** You make something easy to use by making the exported operations
> match the user thoughts/plans/wants.
It did not take me more than 1/2 a second to come up with that "solution".
I seriously doubt that my brain can muster more neurons towards this problem
than anybody else on this planet. I'm sorry if CVS does not cater to your
"spoon-fed" mentality.
> WinCVS does a GUI on the CVS operations. No other abstractions other
> than the CVS stuff. It is a gui, so the organization of the data
> presented is a little better -- that's a plus (better
> layout/organizaation of the data returned means better understanding
> of more data).
Great, a tool, layered above a usefull tool. In other words, a button
doing a series of operations. Sorta like the thing I mentioned above,
in a "script" sense...
> But it's the CVS operations that matter.
Why complicate the matter? Why add "yet another feature, knob, etc", when
the existing framework fully encompases what you wish to do?
> Right now, I can (usually, not always, and no I don't remember why it
> failed when it did) do:
> To decide that I want to create a branch at checkin, with modified
> files:
> cvs tag base-branch
> cvs tag -b branch
> cvs update -r branch
> cvs commit
>
> Why do I need 4 commands to do one operation?
Because you have not discovered high-level shell scripting yet. You claim to
program in high-level languages, why not use them? They are good for more
than just producing code you sell/ship. They can be used to further your
development environment as well, without needing to change CVS...
> Just now I made some changes to files, and realized that what I had
> should have been merged onto the trunk before I made these changes.
> Nothing else had been modified on the trunk since my branching. So, in
> theory, I could say
>
> cvs move-branch removeLocks onto-parent as-branch base-newrevision //
> THIS DOESN'T EXIST -- modify repository only
> cvs rtag -r base-newrevision -b newrevision // modify repository --
> make new branch
> cvs update -r newrevision // switch my newly modified files onto
> newrevsion
> cvs commit
>
> That's another 4 commands, one of which doesn't exist, unless I do a
> lot of diff, revert, patch, etc.
Ok, what is to prevent you from making a diff of your current changes (to
save them), checkout/update on the branch, merge that to the trunk, and then
update/checkout on the branch/trunk you wish to be on, then run patch
against the original diff?
For that matter, it certainly is not a crime to have 2 sandboxes available
to work in, diff from one, patch on the other, etc. As a matter of fact,
I find this a very usefull thing to do/have.
> Why?
Why not? Why unix? Why CVS? Why NT? Why drive a stick? In all seriousness,
CVS was originally developed on unix. I think a lot of the philosophy there,
is the same as in the original unices. We give you pleanty of rope, more than
enough pieces to do what you need to do. More than enough to hang yourself if
you should wish to accomplish such a feat. Just because you wish to have 4
commands done in a certain way, with a certain type of arguments and switches,
does not mean that other people will want that, or will be even able to use
that. At that point, should we ignore their requests for "enhancement" of the
(quite adequate, IMHO) CVS source to appease them? Or should we bloat the code
even more, adding switches to modify the behaviour of this 4-command sequence
in every way possible?
> Why not put all that into CVS? The "flying fish" approach to the
> repository is really the (my opinion) proper way to use it. Otherwise,
> you can only commit a change when it is ready for prime time, or else
> you will hose every other developer.
"Flying Fish"? If your commits "hose" developers, and/or the development
and testing of a product, then your commits are one of 2 things. Either
they are a) malicious, or b) poorly done.
--Toby.
