info-cvs
[Top][All Lists]
Advanced

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

RE: Help understanding cvs logs using cvs2cl.pl


From: Arthur Barrett
Subject: RE: Help understanding cvs logs using cvs2cl.pl
Date: Sat, 3 Mar 2012 23:47:07 +1100

Michael,

> I'm curious what "user defined changesets" are.  Can you point me to
> some docs?
http://march-hare.com/cvsnt/features/changesets/

And that sums up the different approach you and I took.  You assume
Shivani is interested in commits, I assume that that information is
useless for analysis of history or for future project management, what's
actually useful are the user defined change sets.  Shivani specifically
mentioned these (bug numbers).

CVSNT has had user defined change sets since 2004, and SVN has been
talking about adding them for about the same length of time.  User
defined changesets are most useful when combined with 'reserved
versioning' (not locking, reserving) which SVN also doesn't support -
but user defined change sets are useful anyway.

Our own implementations of change management for customers are largely
based on the research of Susan Dart whilst with the Configuration
Management Institute - in summary: change management is only effective
if it can ensure the integrity of all managed items at each development
stage and make the interrelationships clear.  

These relationships are the business relationships: ie: this feature
request (document) led to this study (excel sheet) led to this
functional spec (doc) which led to these java changes, these table
changes and these test requirement changes (doc and script), the tables
and java changes were a part of release 1234, 1235, 1236, and 1237, and
release 1237 is the one that we promoted to UAT and was sent out on the
CD number 987654-321.

Now a month later when a developer is looking at some code and wondering
what it's all about, they can 'see' this is part of a larger changeset -
and click and see all the related components.  Project managers can
promote (or branch/merge) using the changeset, and auditors can audit
the changeset.

An atomic changeset is what cvs2cl gathers - the things that were all
committed together - CVSNT identifies these with a unique atomic commit
id - SVN identifies them with a unique version number.  Neither are
helpful for relating multiple changes over multiple commits by mulitple
people over time.


*rant on*

I've noticed a personally disturbing trend for companies to underfund
open source software defvelopment and keep these critical features in
'wrapper' systems: collabnet put user defined changesets in their
collabnet tool not in SVN core.  Atlassian actively court CVS customers
promising to deliver this feature by 'wrapping' CVS around Jira.  All
that'd be fine commerce - it it worked better that way - but your
repository is the place this information belongs (integrated with your
defect tracker, sure).  That's my opinion anyway.

It makes sense for commercial software vendors to put this in the
proprietary code, not in the open code, because it's what people like
the CMI say is the most important data.  So if that data is in your
proprietary tool, then you'll switch versioning engines (CVS, SVN, Git)
but always use their closed tools to wrap them.  It's simple vendor lock
in.

The CVSNT project gets a lot of flak from some quarters for 'extending'
the 'extendable' RCS format to include this information.  We could have
done a collabnet or an atlassian and stored this in a proprietary
format, but we didn't - we extended RCS/CVS in open source code.  We
didn't introduce any proprietary code at all until we were 'forced to'
in 2010 (6 years after introducing user defined change sets in pure open
source code) and it is entirley non-business code, leaving all this
stuff that is useful to your business open source.

*rant off*

Regards,


Arthur



reply via email to

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