Re: BRANCH LABEL FOR DIRECTORIES

[Ralph Mack]

"Greg A. Woods" wrote:

> Ah, but in this case I can.  Everything I've described about tracking
> the renaming/moving of files using "cvs rm" and "cvs add" with magically
> meaningful comment strings can be easily automated by a front-end.  No
> change is necessary in CVS itself to achieve this functionality,
> therefore it is provably not a necessary feature of the basic CVS
> functionality.

I guess I'm ok with this as long as the format that is used permits
both a machine-automatable comment and a human-to-human comment.
Tactful political commentary is sometimes necessary to explain why
an otherwise competent programmer did something patently stupid:
"RENAME/MOVE -> fubar/coolfeature : Files moved to fubar project due
to management insistance"

My philosophy around merges is that the more frequently they are done
the smaller and therefore safer they are. Any system in which merges are
difficult to get right, where even simple merges require judgement not
only about the source code and what you are merging but what version to
use as a base, will encourage people to do as few of them as possible.

In my view, a version control system should capture and use what
information it can about the versions to make merges no larger or
more dangerous than they need to be. I believe that the smallest,
safest merges generally occur when the version control system uses
for its base version the most recent common ancestor of both the
versions being merged. CVS currently fails to track two types of
historical events critical to making this determination (file
migration and past merges).

They could be collected by a scripting layer above CVS. This layer
could contain the intelligence to query CVS about the merge-relevant
information that it holds and combine it with this collected information
to calculate for each file the optimal base version to use for a merge.
It seems more natural to me that CVS, which already has most of the
merge-relevant information, track the other two pieces of merge-
relevant information and perform the calculation to identify the
optimal base itself as a part of default behavior. Then all of the
merge-relevant information is being tracked together in the repository.

There has been good talk about technical feasibility of keeping the
information in CVS. We've established that there is a place where the
data could be kept in the rcs files without messing up rcs compatibility.
Someone came up with a general work list - a prodigious general work list.

I'm not particularly "religious" about binary files, locking, or empty
directories, the other recently-hot topics on here. I think that hooks
for external diff-merge tools for binary file formats would be a good
move likely to spawn a cottage industry in such things that could only
be good for everyone, since they could be used by all kinds of tools.
Beyond that, I wouldn't want to see CVS go overboard over binaries.
It is a *source* control system based on differencing.

OK. I've expressed my views and have commenced to repeat myself, so it
is time for me to stop talking and put up or shut up. I started
contributing to the ArgoUML project a year and a half ago and then had
to bail a couple of months later due to work; I hated to do it, but I
learned a valuable lesson. I can't pull a passionate four-hour worknight
after pulling a passionate nine-to-ten-hour workday.

If I cared less about my work than I do or did less of it, I could
eagerly pour my heart into authoring the appropriate patches. But I
already have a wife, a son, and a mistress (my work), and I've learned
I haven't the stamina for two mistresses. If I've lit a spark for
anyone else, I will be delighted to encourage them and to test their
patches.

I will continue to comment from time to time in this group (albeit more
briefly - I promise :-)) but I suspect I would be of greater service to
the open source community if I spent an hour or two a night testing some
worthy open-source project and filing bugs or picking up filed bugs and
fixing them. If I lack the stamina to do what I would like, at least I
should do what I can. Maybe ArgoUML will take me back on that basis...

Ralph A. Mack