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.
Gerhard, Thanks for your comments and suggestions. >> How is this different to what CVSNT already does? > > I don't see that CVSNT does this at all. When merging in a sequence of > changes (that is, if you're not merging from the top of a parallel > branch), > I think there are two methods: bug ids and the update merge with two -j > options. The single -j merge does not necessarily have to come from a single parallel branch. As long as there is a shared root at SOME point it works. I've never seen an instance where a single -j (ie: a mergepoint) does not work. If you have one please give a diagram or talk us through the branches and when/why they were created. Basically the single -j merge is simply merge -j this-branch to my current one. I do almost always qualify a -j merge with a bug number, so there may be something I've never seen here, but then again I don't know why anyone would not use a bug number... >> How would making this "one command" be significantly better? > > The difference is that if it is a command of the versioning system, you > have a higher probability that you can build a procedure on top of it, That seems to be similar to saying that "ls" should have a "grep" option since doing "ls -la | grep drw" has a low probability of working... > because you're more likely to find consistent support for that. If it is a > TCVS feature, the people who can't use TCVS have to provide their own > support for it (which is relatively easy on the command line, but more Yes. And I think this is a good thing not a bad thing. For instance the Eclipse team have written some very nifty functions by using nothing but the basic CVS 1.11 commands, it makes their Java IDE more popular than some others. Recent experience shows that adding "features" to CVSNT does NOT result in them getting added to GUI's (unless we do it ourselves), but adding low level functions that can be combined in a number of ways is likely to get used (eg: "cvs ls"). Occasionally someone will ask me "what GUI should we use" or the variation "why does CVS Suite include so many GUI's" and the answer is that different people/teams work different ways and the different GUI's are designed for different audiences. My limited understanding of your "combined branch/update/commit" command (should be call it "cvs buc"?) is that only people following a very specific CM process and in a particular dev env would find it useful - an ideal target for a specific GUI... We've intended for some time to ship a "combined client" that includes everything needed to get going in one installer - we already provide it to commercial clients but we are starting to move towards that in the open source version with 2.5.04 too, and it'll eventually get further. At the moment I think a lot of people discard CVSNT since there is no "GUI" and almost everyone I've ever met has no idea TCVS has any dependence on CVSNT (which shows how sealmess TCVS's result is). I'm personally all for increasing our relationship with other FOSS projects so that ideally we can each offer our own "pieces" but also offer a "combination" that makes it easy for people to get started. With regard to your particular "problem" - I suspect the problem lies elsewhere and as a CM architect I'd be reluctant to solve it technically. If conflicts at commit are occurring so regularly to cause delays to the project then "cvs buc" simply moves to problem to another person (QA?), and the problem really lies in the design of the project (probably one file should be split into 20 or 30, or there should be several variations, eg a US, a EMEA, Asia etc). If you or someone else wanted to add "cvs buc" you are welcome to and we'd happily add the code to the base, but as it stands I do not see justification for March Hare to spend time on it, at least not in CVSNT or EVS, but in TCVS it'd be a possibility and very little effort. >> What business problem does this solve? > > What business problem any of this solves -- or whether it solves a > business I generally do not ask rhetorical questions. If there is no business case March Hare wont do it. Before any line of code get's approved there is a specific audience, $ value (in terms of increase sales of the commercial product) and comparison to competing products and industry analyst or media comments (eg: SOX requires auditing so CVSNT got Audit, CMI determines that value in SCM implementation derives from finding relationships between changes so CVSNT got but id's). So show me an analyst report that describes what a problem this is for business and how much it is costing, show me a media article decrying the lack of this feature in a competitors product, show me your company's annual report citing this as a reason for a lower than expected financial result, show me some business benefit - not just the desire for a new verb and I'll happily reconsider. I think the easiest one to pick would be "lack of developer productivity due to complexity of software, resulting in additional overheads and slip in project schedules", however that plainly points to TCVS as the solution (or CM process re-engineering). Of course just because I am not interested in spending time coding this feature doesn't stop you, since you have the source. In addition to Tony being paid to work on this stuff 8 hours a day, he also spends some of his own time on it and adds some things that he just wants to add, everyone are entitled to do that - it's the "free(dom)" in "free software". I can say that it is eventually our goal to have each EVS verb to be a separate DLL/shared library so that any 3rd party can add an EVS verb without affecting the rest of the app. This should make it easier to add new verbs that needing to re-compile all of CVSNT or EVS, however I do not think that is a version 1.0 deliverable, and I also do not know if Tony has given any thought to one verb calling another verb... Regards, Arthur .