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 < [email protected]> 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
