Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
Kevin McGuire wrote: > Q: If a bug is fixed in the Linux version, how and when does it get > migrated to CVSNT? If someone reports it here, or it's major (such as the double-free bug a few weeks ago) then it's fixed as soon as I hear about it (there are communication channels between the Unix and cvsnt teams for security issues). > Q: Similary, if a new CVS Linux version is released, how does this migrate > to a CVSNT version? They don't really correlate... it hasn't mattered because the Unix development cycle is slower (they favour stability over features, whereas I try to balance the two). If there's a feature that someone wants they'll usually ask about it on the list & it'll get implemented if it looks good or is needed for a specific reason (if one of the WinCVS or TortoiseCVS developers request something it'll generally get in faster as they're in my 'supported' list. There's no reason that Eclipse couldn't be done on that basis, too). > Q: Aside from NT specific areas, do fixes in CVSNT find their way back to > Linux, and how/when? Or, is there a common code base that always moves > forward on Linux and then is migrated? There's no reason why the Unix CVS developers can't use CVSNT code, but there hasn't been much the other way yet. AFAIK some of the Unix cvs developers do read this list so they are presumably aware of what's being developed, etc. > Q: How many active committers are there on CVSNT and how often do they > work > on it? I am trying to understand the size of the push behind CVSNT > maintenance and the frequency. It tends to be just me, with people reporting bugs & sending patches that I integrate. The load is quite low, since in reality not so much changes... it looks like a lot sometimes but most of the features that have been added recently have been less than a days' work. At the moment I'm on a stability push, since I did some much needed restructuring of the RCS code but it made some of it a bit fragile. Build 72 seems to have reached a level of stability I'm happy with, so I can slow down for a bit and maybe think about what features there are still on my 'todo' list. > Q: What problems do you see with the maintenance process? For example, > do you find it works well, or do you need more active committers, or > committers who can spend more time on CVSNT? There is a test script that runs on both NT and Linux, but it's not complete enough yet... I add to it whenever a problem occurs so I'll catch it next time. Hopefully it'll get to the point that I can say each release is solid based on the test results. Mostly I just need feedback... especially from people willing to try the 'experimental' features such as atomic commits. There are some other projects that could probably do with external input (such as distributed repositories). In an ideal world the server could be progressively rewritten but I've tried that a few times and there really isn't the time to do it and maintain the release at the same time. > Q: Are there people who work on both CVSNT and CVS linux mainteance? There is communication both ways but basically they're separate. > Q: It seems that the appearance of CVSNT versions is somewhat > uncorrelated > with Linux versions. For example, there may be nothing for CVSNT for > awhile, then several versions (usually minor 'letter' version upgrades). > Is > this accurate, and if so how does this come about? For example, is it > because a committer will book off some time and work a lot on CVSNT, then > can't for awhile due to requirements of their "day job"? The 'letter' upgrades were what happened after I branched a development release and forgot to leave a gap in the numbering system for the releases to continue. We're back to numbers now. Ideally the release cycle would be every couple of weeks but it isn't planned as such, it just happens when there's something that is stable enough to release. Because of the rapid releases I generally don't mind if people are using 'old' releases... I recommend that people use the one that works for them and only upgrade if they have problems. Any changes to the cvsnt output are usually 'consistent' as I try to keep the output parseable - for example the extra fields in 'log' are just appended to a semicolon-separated list that is already there, and the extra lines in 'status' are in the identical format to other lines. I try not to break things, but relying on the output remaining static is probably a bad idea. If you see an incompatible change in the future I'm always open to negotiation if changing it slightly will make things easier to parse. Tony