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/Peter/Tony, It's good to see some technical discussion about EVS (and a GIT layer) however the conversation really belongs on the EVS newsgroup. The problem with having it here is that it'll be difficult to find in a years time, and people who've subscribed to the EVS newsgroup because they are interested in new layers (like a Git layer) are missing out on contributing to the discussion... Even the title of this thread is innapropriate... Here follows some (mostly non-technical) observations. > And yes the are all the same, at heart. That's the depressing thing > about it.. they all go off writing new ones instead of > improving what's there already and end up with something that is > basically the same thing with a new skin on it. Many people do not realise just HOW SIMILAR these systems are even when the resulting workflow is quite different; however it does highlight just how wedded to a single workflow people can become that for someone else to use a different workflow they feel the need to rewrite the tool from scratch. This is what led to CVSNT forking from CVS: a couple of small changes to enable a new workflow were rejected as possible changes to CVS 1.10... If you spend a lot of time offline (like on a train) then you can already achieve an identical workflow to Git by using CVSNT 2.5.04 and a local proxy (ok - it wont allow you to commit while offline, but the next version of EVS would even let you do that). > Users are picky about the tools they use, and many (perhaps > most) are very unhappy about going outside their comfort > zone. Rather than people being 'pretty indifferent to switching tools' (as someone wrote in this thread) we find it almost like a dark-ages mediaeval religious battle. People fight tooth and claw to use their preferred client - though usually expressed as a desire to install a server: SVN or CVS or GIT when all they really care about is a particular defined workflow/client. > give them a list of old and new commands, and that's it. Far from it - but it's not 'resistance to change' it's fashion. A percentage of people want to use the latest toy, no matter the benefit; they wanted to use SVN last year and GIT this year, YouTube one year and facebook the next and are currently off twittering somewhere. Enterprises want to attract these talented people but need to keep a sane and centralised change management system - which is why it was worth writing EVS. > I think this is the important part. DVCSes suddenly open styles > of collaboration that previously simply impossible. . . . > That's the actual wonderful thing about git and the other DVCSes: > I would just clone, say, the cvsnt repo, and work on some features, > and I can do so under version control. When I'm done I can just tell > you to pull it back -- no need for committer status or nothing. A lot of people blame *tools* when the reason for certain limitations is *policy*. Andreas' example of being able to change a file he doesn't have access too is NOT a failure of the tool - it's a policy failure (or at worst policy implementation). If the corporate policy is to NOT allow you access to write that file - then that's the policy. If the corporate policy is to allow one person to write to the repository on bahalf of another person then that is the policy (different 'username' to 'author' - EVS and CVS Suite both have this feature). EVS is capable of 'impersonating' other SCM servers like CVS, SVN, TFS and one day others probably including GIT - however there will be (potentially large) operational differences because of POLICY. If the corporate policy is to prevent writes to the revision history where username is different to the author then it will be disallowed regardless of the client tools' support for that feature. Note: if you make the change then it is your change not someone elses and the SCM tool would be failing basic audit checks if it did not record that. CVSNT (and other 'free' SCM systems) have frequently benefited from this - it's a two edged sword - often a company will have ClearCase as their SCM system and have all the policies implemented, however someone doesn't like the POLICY and blames the TOOL and so covertly installs CVSNT so they control their own policy. Whilst this helps the profile of our project it is a fundamentally flawed approach to SCM and to employment. I've also seen plenty of cases where a commercial SCM system is implemented with arbitrary policies that unnecessarily hamper the efficiency of the team. Too many people confuse TOOL with POLICY, ie: This tool wont let me do xyz; when it's: The corporate policy is not to do xyz. The best question to ask is: is this a valid policy - should it be changed? To me GIT (and similar tools) has a fundamental flaw (for commercial software development). In Intellectual Property and Copyright law cases for software the only line of defense that a company has is to show unique parallel invention - ie: that the feature was invented and implemented not 'copied'. If a developer does all of their 'small' changes on their 'own' repository then push up just the 'result' then leave and take their 'own' repository with them (or it's lost or deleted) then there is no way to defend spurious claims in court. Or a far simpler problem: the laptop is left on a train and the local repository hasn't been 'pushed' back to a master repository for a few days/weeks/months... > Looked into darcs? As far as I heard they can record variable > name changes as such. I don't know darcs at all, but I think this feature is similar to the 'property' feature of SVN which CVSNT has had for years and years and now EVS has it too. > evs has more fine grained object tracking than any system > currently out there (that I've seen) and at the same time > can represent changes at the repository level if required. The real bleeding edge of SCCM is line/block revision control so that the SCCM system can identify that all these projects have about() functions, and these are the variations to them; that all these word docs have these 'limitation of liability' paragraphs and these are the variations to them - and indeed to be able to arbitrarily 'merge' or 'replace' them all. All tools I know of are currently file based, not block based - and we even discussed doing this with EVS however it was (wisely) decided that we'd already tasked ourselves with a big enough problem... Regards, Arthur Barrett