info-cvs
[Top][All Lists]
Advanced

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

Re: What about tommorrow?


From: Ralph Mack
Subject: Re: What about tommorrow?
Date: Fri, 20 Jul 2001 00:33:30 -0400

> So.... If we, the community of CVS users, decide that we would like to see
> "non-mergeable" files handled differently than they are currently, then it
will
> be made so?

> Really?????

> Can I have a show of hands, please! :-)

This is open source - nobody gets to vote until somebody writes the patch.
:-)
But then nobody will write the patch until they believe it has a ghost of a
chance of being accepted or they believe it will become used in spite of not
being accepted into the formal build.

At present, the user community is split between people who need different
kinds
of tool and the question is what kind of tool CVS should be. The obvious
answer
for each person is "The kind of tool that *I* need, of course!"  Somehow the
team leadership needs to sort out these disparate voices and set a
direction.
Mr. Jones has indicated conservative preferences; I can respect that.

Better merge support had been a big item for me but I have begun to have
doubts about many of the things I had been using branches for and this
illumination reduces the need for merges dramatically. With merge issues
now taking a much smaller role in my thinking, I find I only lack for
three important things:

- The ability to safely manage revision streams of all files from which all
  of the artifacts of a project are built.
- The ability to setup and administer the tool without having to know
  much about how it works inside (but without losing the ability to look
  and even fiddle if you want to).
- The ability to control the level of detail in repository queries without
  having to resort to writing scripts.

I can imagine a GUI-based repository administration and flexible reporting
tool
layered on CVS that would cover the latter two requirements. It might even
be a
fun way to learn GTK+. However, whenever I try to imagine a tool to
seamlessly
integrate CVS and a binary file versioning system (BVS?), I end up with the
BVS
needing to share at least CVSROOT and the user's sandbox and borrowing a lot
of
CVS code to do everything so closely to CVS that users can't tell the
difference
except for the absence of merges and the ability to read the 100th revision
of
a big CAD database.

Ralph A. Mack




reply via email to

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