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: Shivani Rao
Subject: Re: Help understanding cvs logs using cvs2cl.pl
Date: Sat, 3 Mar 2012 16:12:19 -0500

I want to track both, software evolution and the bugs
i do not think that all changes are made for a particular bug, sometimes a
change is made for feature addition too.

So I wanted to track both.


On Sat, Mar 3, 2012 at 7:47 AM, Arthur Barrett <
address@hidden> wrote:

> 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
>



-- 
Research Scholar,
School of Electrical and Computer Engineering
Purdue University
West Lafayette IN
web.ics.purdue.edu/~sgrao


reply via email to

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