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.
Andreas Krey wrote: > Most software is written and then a bit modified, and then stays, > which means repositories don't grow over time, but mainly with > the code size they contain. Which explains why git often manages > to have the repository smaller than the (uncompressed) tar ball > of the head. A valid and not uncommon model is to keep the resultant binaries in the tree for each released version. Some even go as far as to keep the installers for all the compiler versions in there as well, so they can guarantee they can replicate a build. Binaries don't compress very well... by the time you had half a dozen in there you'd be talking about some serious repository size. Worst case is those places that put ISO images of their releases in the reopsitory as well! > Which basically means that you need to enable compression if a > cvs checkout of the head shall be faster than a git clone of the > *entire* repo. cvs checkouts are generally always compressed.. but the last time I grabbed redhat it took 2 hours on a fast link. I only wanted a couple of files... > I happen to travel by rail, and while there is GPRS etc., it is > a bit flaky when you actually move, and it's not exactly fast. > You definitely don't want to do lots of 'cvs diff's there. Depends on how you work - I rarely do cvs diffs for example, unless I'm checking a commit, and if I'm doing that it's in the office. > Those people would also be pretty indifferent to switching tools; > give them a list of old and new commands, and that's it. As Arthur points out, that's not true - those kinds of people are often the most resistant to change. > Unfortunately, those (the mergemeisters and generally those who > do the difficult stuff) need to be in the boat. If you omit these > 10% you got an acceptance problem at least where such people exist. There's stuff that people never do, except in rare exceptions. You'd be surprised - we've had stuff break in cvsnt and it been 18 months before anyone actually noticed. People think 2.5.03.2382 is pretty stable (and it is, generally) but there are several hundred bug fixes since, some of them major.. except they don't use that bit so don't notice. > and lots of general (command line) usability stuff. Just how often you > have to type repository urls to svn is annoying. (Although the price for the > biggest shittyness*popularity product goes to ant.) Never saw the point in ant. > I note a trend there. :-) Namely the reliance on the commercial > business case (which is nothing to boo at). For evs, definately. It's a big server aimed at commercial customers, so they drive the development. Everything in there so far (AFAIK) is stuff that companies have asked Arthur about. > Conflicting commit resolution? Can be handled by the admin when they need it. In practice it doesn't happen - if you have a team in the US and a team in India, for example, they'll be working on different modules. They may call into each other so they need each others source code, but they won't be modifying each other. Where teams are working on the same modules we've got that covered. > 'normal' as in 'centralized VCS', of course. :-) The problem is the > administrative overhead in that, the distributed VCS are a lot more > democratic (or anarchic) there. Not so much.. create a branch, setup access control so only that user can write to it. 5 minutes max. Tony