[Top][All Lists]

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

RE: mechanisms for reviews needed

From: Arthur Barrett
Subject: RE: mechanisms for reviews needed
Date: Tue, 2 Aug 2005 07:23:52 +1000


>> I would have proposed all this but you said that you didn't want to 
>> use branches....
>Actually, I don't really care how it is implemented. I guess there must

>be a branch under the hood keeping track of the pending commits.

OK well there is a common ground then...

>What I meant was that I don't want to stretch the tool in order to fake

>what I want; This is such an important feature that it should be at the

>very heart of the VCS engine.

In the CVS world the graphical front ends lead a life very separate to
the actual engine (and tend to live several generations behind).  It
will probably therefore be a while before the GUI's like Tortoise and
WinCVS catch this trend.  We produce our own customised Tortoise for our
commercial supoprt customers - how would you expect this to "look"?

>The main difference from CVS is that it is _transaction_ based. 
>You bundle a set of changes into a _revision_. The revision gets 
>an ID and you submit the revision as one unit. It is put into a 
>pending area where everybody can fetch it. They can then build it 
>locally, and test it. The assigned reviewers will accept or reject 
>the revision. When it is accepted, it gets commited to the repository 
>automatically. All communication of revision status is automatic 
>and e-mail based.

CVSNT calls these things bug numbers.  I have heard other people call
them change sets.  CVSNT has two ways of grouping changes:
* commit id (which is unique per commit transaction)
* change set number / bug number (which can be retained over several
modules/directories/files/commits, and can contain several revisions -
ie: change 123 began at revision 1.2 and finished at revision 1.5).

At the moment we have added the structural elements so this CAN be
implemented in CVSNT, but it is not obvious - that I would see as
something a GUI could assist with, but is usually the realm of

A lot of SCM tools are integrating processes into the design of the GUI,
and I personally am a little cautious, since it only works if that
process 100% matches your company objectives and culture - otherwise it
gets in the way.  But that'll take us into a philosophical discussion...

At this point the CVS people have probably had enough of this discussion
- this type of development is not what CVS was originally designed for
(they have a similar but different definition of cooperative development
which works very well).  

Please e-mail me a reply off this list.


Arthur Barrett

reply via email to

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