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
