On Tuesday, March 7, Michael Gersten wrote:
>
> We have a very different philosophy here.
Yes we do, but in a strange way, I'm actually enjoying this debate. I'll
appologize right now to any/all of you on this list behind slow/expensive
connections...
> The ultimate idea is this: When you check out something, you get a local
> copy; you then track changes to it; when you are satisfied, you commit it
> back to where you got it.
> The current CVS update/commit, without built-in support for flying fish,
> does not support that middle step: track changes to it.
Ahh, I think you need to look into tags. One place I worked, not necessarily
the best way of doing it, had a number of tags (not branches), which were used
to help in this regard. The head of any branch where development was going
on, there was a tag which was the tag used to build off of.
In other words, each night, a new head-version was checked out, built, run
through tests, etc. If that version passed, the original tag (which built
the time before), was moved forward to include the newly working sources.
In this way, developers were "free" to commit on the head of the branch, doing
their development, but a "working" version was always retrievable by updating
on the tag.
Branches were used to do 3 main things.
1) On product release, a branch was made, in this way, any/all patches to the
product were done on that branch. Note, it is hard to hold off on doing this
branch until the last possible moment, especially if there are other people
working on the next version before the current on is out. The "less" stuff is
on the branch you are shipping from, the easier it will be. Less code will
have to be merged back to the trunk. To keep track of merges, people used
tags to identify what has/has-not been merged.
2) Major rewrites, in parallel with current development. This tends to be
something like a switch from C to C++, or other major things like that. It
usually entails a major effort on the part of the developers working on the
branch to keep up with merges from the trunk. The final merge back onto the
trunk usually becomes more of a replace, than a merge.
3) Exploration. This one I've seen happen, and be abused as well. Developers
trying to explore the option. Something close to #2, but potentially never
merged back into the trunk. I tend to discourage this reason for branches.
> > > 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...
>
> No. When I need to, I write the find ... | xargs. The windows find tool
> only supports looking for one type of file, or all files; it cannot say
> "any non-directory"; it cannot say "modified in the last 10 minutes" (but
> many find's cannot either; the apple one on web objects cannot).
>
> The find construct takes longer to write, and double check. Yes, it's more
> powerful. But it's slower to use.
But this is where scripting comes into play. Or simple shell aliases if your
shell supports them. The underlying tools are general enough to allow you to
make as powerfull and simple an interface to them as you wish.
Ok, allow me to "edit" or rearrange your e-mail a little. First you say:
> I like convenience. I do not like to be limited by convenience.
Then later on we get to:
> > I'm sorry if CVS does not cater to your "spoon-fed" mentality.
>
> Now that's personal. I do not have a spoon fed mentality.
For this, all I can say is that "spoon-fed", and to like convenience over
utility and power, are the same thing. And yes, it was personal. I'm glad
you did not take too much offense at it.
> Think X windows. Now really think X windows, and novice computer users.
> Now look at how big your X-windows modifications file is, and how long it
> took you to build it. I lost mine when I left UCLA, that I spent years
> building up/improving; when it was lost, that was when I realized just how
> bad the X environment was.
I have to think of this all the time. I'm a sysadmin for the CS department
here at the university. Allow me to tell you a story, a little related to X,
and making things "easier". 7-8 years ago, when I went through university,
not here, things were not "spoon-fed" to you. You had to think, setup your
own things, use the tools given to make an environment in which you could be
both productive, and efficient. In some sense, it seperated the men from the
boys, and even furthered communication and community among the CS students.
In todays' university environment, we are told to "standardize", to make sure
that students have a GUI to make things easier on the students. To let them
focus on writing their quick-sort algorithms, etc. I keep having to remind
people that the general access unix pool does not cater to students in this
way, and people use it all the time. They like it, and are productive using
it. Why then do we have to pamper and spoon-feed computer science students?
Yes, I have an "X-windows modifications file". Or an ~/.Xresources, and
an ~/.fvwmrc file. I figure I've got roughly 1000 lines total in them.
Certainly, I would not like to "loose" them. But I'd hate it even more if
I had to restrict myself to using one "standard", totaly non-extendable
interface, something like a mac, or windows...
> There is no reason that a gui can't be written like the windows gui, that
> builds up a command-line string on the bottom, that you can use as a
> starting point, and then make a minor change to the command-line string
> with the keyboard and hit 'go'. Use the gui to build the starting syntax
> blocks, add the odd-argument manually. No one does this, I don't know why.
I think I can tell you why. It is also the reason why I use the mouse so very
sparingly, even in my "GUI" environment. (I tend to use X). It takes time to
move your hand off the keys, and actually drag/drop/click the right sequence
and combinations of buttons in order to accomplish what you wish.
> I do not consider GUI to mean 'easy to use', nor do I consider command-line
> to mean 'powerful'. Nor do I consider the two _inherently_ incompatible.
No, but I think you'll agree with me, that for most tasks, a GUI interface as
powerfull and flexible as a command line, will look remarkably like a terminal
with a command line interface... Yes, there are "push button X or Y to create
application Z" type of GUI interfaces out there, they tend to be restricted in
what they can do, or be very large and unwieldly in order to handle the config-
urability...
> Yes, PERL would let me do this better, do better error checking, etc. Have
> you seen the thickness of the perl manual when you print it all out? Have
> you tried watching someone who is learning perl 5.003 from scratch trying
> to read it, and dealing with all the 'what the blazes ???' in the first two
> real chapters? (syntax and datatypes) (That's as far as I've gotten so far
> -- I've moved, and haven't unpacked (or even found) the manual yet).
I'm gonna get a little more personal here. You complaining to me that PERL
is too high level, and too feature rich now!?! First you wanted something
non-assembly like. Now PERL is too much. If that is so, maybe emacs-lisp
is more your style? :-)
> I haven't gotten through it enough that I'd be comfortable writing a large
> perl script, or even a mission critical simple one.
That's why you hire people like me! Well, sorta like me, anyways...
> Just as an example: Sybase's stored procedure to rename a database element
> is something like 1200 lines of SQL. 5 lines to do the rename, 1195 to do
> error checking.
Not that this has much to do with the issue at hand, but if you are using 400
times as many lines of code to check for errors, as you are using to actually
do the work, there is something fundamentaly wrong. Maybe not with the way
you wrote the procedure, but maybe with the language and/or environment it
was implemented in.
> You want me to do all that in a script, covering all the possible problems
> that can arise, etc, when the CVS code has subroutines and libraries that
> do 80-90% of what I want already?
Are you saying that CVS has these routines, but prevents you access to them
using the standard cvs binary?
> How about this compromise: A CVS command to walk the local sandbox, find
> all the patch reject files, and mark conflicts properly? (With an option to
> clean up the patch output files afterwards, perhaps smarts or a switch to
> remove those patch outputs that were successfully dealt with already/prior
> run/manually, etc?)
Nope, this would be better suited in the "patch" binary itself. It is already
"walking the tree", since it is going after the patch file. It could have a
"cvs mode" of sorts. Not really the way the patch maintainers are likely to
do it though...
> Or a CVS command to take diff files as input and apply the changes, marking
> conflicts appropriately?
Hmm, this one has some merit. We do have a "diff" tool within CVS, so why
not a "patch" tool. I'd veto it on the grounds of bloat, patch is by no means
a "small" tool. On the other hand, I'd see it as a way to round out the
support that CVS would/could have for diff/patch...
> > > 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...
>
> No. It is a GUI interface -- meaning that it has better layout, better
> presentation, etc.
Irrelevant. It is a tool, layered on top of another usefull tool. Just
because it jazzes things up with graphics, and "usefull" layouts, does not
mean it is "better" than a script which uses CVS to do something usefull.
Each "button" or GUI HCI dongle, is a means to invoke a number of CVS and/or
other commands. Much like typing a shell alias or a scriptname can give
invoke a number of CVS and/or other commands.
> It has much better support for the log command -- it can graphically show
> you all the branches made, and the tags assigned, in a way that you can see
> what goes where.
Great, it has *graphical* support for log. However, I dare you to print-out
an ASCII representation of that view/window, and then use PERL, or another
language to do *anything* usefull with that information. I know that "cvs log"
is not as "pretty" as it could be, nor as easy to parse as it could be, but
it is largely consistent, and much more easily parsable than an ASCII "tree"
view.
Of course, the "tree" view that WinCVS gives you may well be better suited to
your understanding of how log messages relate to commits and branches. Bonus!
Again, a tool, usefull tool, layered on top of another usefull tool.
> But everything that it does turns into a single CVS command. No scripting.
> No support for a series of operations. The same primitives that CVS has
> (with a few cases that they didn't think of supporting).
This is the "degenerate" case of scripting. You've replaced the command "cvs
commit" with "move mouse, click on button".
> > > 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?
>
> What is the job of CVS?
Well, as I see it, it is to give you roughly 4 things:
1) Ability to store and retrieve different revisions (text) files in a
semi-efficient way.
2) Ability to tag specific revisions with a largely arbitrary tag name, and
the ability to use this tag-name instead of numbered revisions to work with.
3) Ability to create branches to help with the parallel development of
different stages of the same software. To aid in the separation sometimes
necessary in complete rewrites of particular software.
4) Ability to work in the above environment, without resorting to locking.
The ability to make the "copy-modify-merge" paradigm work.
> Is CVS supposed to be a source code tracking system, or a functioning
> source code tracking system?
Functioning is up to you. It is a source code tracking system. When and
how you commit, "after each line is edited", or "after you have something
working", is largely up to you. My suggestion of using tags to mark working
versions of software may help you out in this regard.
> I can write a script for this. And, test it. I find that it works for my
> test cases.
>
> I don't know CVS. I don't know it's ins and outs. I don't know all that it
> does; I don't use all that I know.
>
> I know that I don't know enough to know how to test this, or even what
> failure cases can occur.
Just because they are scripts, does not mean they do not have a development
cycle. They will need development, testing, deployment, and then patching.
The joy is, you'll have the ability to use CVS to aid you in this quest!
> As I said, it _USUALLY_ works. I don't know why it doesn't when it doesn't.
> I certainly can't make a script to cover errors that I don't know of. The
> next time it fails, I'll know (because it's now important to me) to find
> out why, and fix it. Then, maybe, I can write this script.
Exactly, a development cycle. You ain't gonna get it perfect the first time.
Nor the second. But over time, things tend to improve...
> > 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
>
> Tell me the CVS command to "Merge this up one level".
>
> "cvs update -A" will get me back to the trunk from any level down of
> branching, assuming that nothing is modified.
> What is the flag to update to only go up one level of branching?
> What is the command to move elsewhere on the tree only if it won't cause a
> conflict, or if it won't cause a merge?
You can do diffs between pretty much any two revisions of a file. So, if you
have something that you commited on a branch, between two revisions, and you
need to move this to the trunk, you can take a diff, and use "patch" to help
you in the "transplant" of the code. Of course, your milage will vary,
depending on how close the two codebases really are...
> Hmm. 2 sandboxes on different branches is a good idea. Thank you.
> (No, I don't think of everything. Things that are obvious to me are not to
> others, and visa-versa.)
No need to constrain yourself. :-) I realize this may be harder to do for
people that work on multi-100-megabyte sources, but it is still possible...
> > Why not? Why unix? Why CVS? Why NT?
>
> Because of my job. THat's the only reason for NT.
Pitty you. It's a virus, get out while you can! ;-)
> Ok, consider this:
>
> Back with RCS, the commands where ci, co, etc.
> You could easily add a new command.
>
> Now, the commands are 'cvs ci', 'cvs co', etc.
> Do I tell people (co-developers that have less time to learn cvs than I do)
> that some commands are 'cvs foo', and others are 'mycvs foo'?
> How do I, and how much time do I spend, duplicating the left side
> arguments? What about duplicating the right side arguments that are common,
> and have a great deal of support in CVS that I have to start from scratch
> with in a script?
[snip]
> CVS has no support for adding new user commands -- so that I can write a
> script, 'mgmerge', and then say 'cvs -z9 -q mgmerge <options>'. With the
> goal that 'mgmerge' would be called in a known environment, with it's
> options, one file at a time, and it will work as expected, whether the user
> has a -n on the left or not. Does this fit the job of CVS? (Probably not,
> at least according to the current job description. Is this wanted? Is the
> job description for CVS proper?)
You make some very good arguments, and good points. I could see some usefull
things come out of making CVS extendable in this manner. This would satisfy
my minimalistic view of what CVS should do. It would/could help the people
that wish to get rid of 'cvs edit' to do so, and it would also allow people
to add 3rd-party supported 'cvs lock' (oh no, evil!) functionality.
However, I can see *SIGNIFICANT* problems in getting this to work. I'd say
that at the very least, the non-client-server things within CVS would have to
be nuked, and chances are that the client-server protocol would also need a
significant overhaul...
> What do you want to be able to do with a source code tree?
> What operations do you want to be able to do?
> What do you want to be able to do with branches?
All good questions, however, I believe that in order to change CVS to support
all the possible answers to these, significant changes would need to be done.
Chances are the underlying RCS format for the repo files would need to be
changed, along with a host of other things...
I'm not saying these are bad things. But I am thinking that they don't belong
in the current CVS codebase. They belong in a new codebase, built up with such
things in mind, etc...
> <<<CVS does a pretty good job at hiding these so called magic branches,
> but in a few places the hiding is incomplete...>>>
Again, a rather unfortunate thing. Something that would be nice to see go
away, but again, without removing RCS, and replacing it with something else,
chances are this will not happen. It will also change the way that CVS has
done this for a long time, necessating changes to scripts that expect this
behaviour...
> So again, my questions to you are:
> 1. What operations on branches do people really want/need/use?
To be truthfull, I very rarely use branches. They are rather painfull to work
with. (The one admission I'll make...) But when they are necessary, then no
other method really works...
> 2. What operations does CVS support?
> 3. If they do not match, why not? Is the answer to #1 really so huge that
> it can't be done reasonably? If so, is there a better set of primitives
> that come closer? Can the set of primitives be extended/enhanced with some
> non-primitives?
Ahh, development. Well, you will find opposition to "changing" how branching
works, unless you can convince all the people that like the current way, or
can deal with the current way, to actually change to a newer, different, only
potentially better model. Not easy things to do.
> I don't want my tools to be the lowest level primitive possible; I don't
> work in assembly. I want my tools to be usable. I want my tools' supported
> operations to match the actual use behavior of what I do with them.
> I want to step on shoulders, not on toes.
Again, CVS is pretty much what you get. There are things being done to it,
and some of them may help. If you think that CVS's shoulders are closer to
the toe level, and you can't work effectively with a tool at that level, it
may be time to have a good hard look at other VC tools available. I've heard
some good things about some of the commercial offerings, especially with
regard to branching and merging support. Of course, most of them will take
150 times as much money/resources to do a comparable job... :-)
> Is that wrong of me? Am I "spoon fed" for that?
In one sense, yes. In another, no. Certainly not wrong of you.
> "The reasonable man adapts himself to the world; the unreasonable man
> alters the world. All progress, therefore, depends on the unreasonable
> man".
In this case, CVS is the world. The source is there, feel free to alter
it. If people like what you did, you will have changed CVS (the world).
> I'm trying to point out (and if I'm wrong, say so) that the operations that
> CVS supports for branches do not match what people want to use branches
> for/what they could/would use them for if they could/would do more.
That may be very true. Again, if you can code up way of improving branch
support, and people find it is a generally usefull "patch", then I would not
see much problems with seeing it integrated into a future version of CVS.
> Sorry for the length of this.
No need on my part. Sorry to people with slow/expensive links though...
--Toby.
