I think this discussion is at the wrong level. Distributed version control systems are becoming very appealing for certain kinds of projects. The decentralized nature of use is particularly useful so long as the conditions are right.
Posturing about whether SVN is going away and that's reason to abandon it in favor of a new shiny thing doesn't strike me as very constructive, however.
I think the more-important questions are about the use cases and constraints on git or Mercurial in a way that satisfies the governance, transparency, and auditability requirements for the operation of OASIS Technical Committees.
By the way, the OASIS OIC TC uses the SVN repository. We need more practice with it and a work flow that leads to "official" artifacts in an auditable and back-traceable way. I have no information that suggests the SVN repository is unsatisfactory. I am concerned about what might be broken by going to a rather different versioning methodology unless one can be more forthcoming about specific, tangible benefits.
In the case of the current support for SVN and any replacement technology, I think there are some immediate matters to discuss:
1. How are commits made to the "official" repository?
2. Who has to resolve merging and conflicts that arise in merging? Who can?
3. How are notifications made of changes and commits to the TC version-control repository?
4. Is a web view and the ability to refer to versioned items (and their specific versions) still available, and by what means? Are there durable URLs that can be employed?
5. Can the repository be viewed and navigated using a stock web browser?
6. With regard to committers, how is the control of those with commit (versus access) privileges tied to OASIS TC member authentication, or some other authentication, and who administers it?
As an individual developer, apart from not having a shared revision history, I can and do run multiple version control systems and I can have working copies that are associated with SVN and also git/Mercurial (and even VSS, which I still use because of a sweet spot it handles for me). It doesn't bother me at all to interact with an OASIS TC repository implemented on SVN even though I may have a finer-grained repository that I also synchronize with that working copy all under my own responsibility and off-line as far as the remote SVN site is concerned. This would certainly be the case if I was testing and debugging and making changes to test scripts or code or examples that are posted from time to time in a more-finished state to a TC SVN. The use of SVN is not a burden.
It is not clear to me that the OASIS SVN is broken with regard to how it serves the OASIS Technical Committees in the context of the OASIS use cases. I am reluctant to entertain fixing something that is clearly not broken, considering the many other concerns there are to deal with beside having a workable versioned repository.
- Dennis
Original Message-----
From: Farrukh Najmi [mailto:farrukh@wellfleetsoftware.com]
Sent: Friday, April 09, 2010 13:12
To: Peter F Brown (Pensive)
Cc: oasis-member-discuss@lists.oasis-open.org
Subject: Re: [oasis-member-discuss] Request for mercurial or git distributed VCS