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.
On Thu, 09 Apr 2009 15:19:54 +0000, Arthur Barrett wrote: ... > 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... What was that? Merge support? ... > server: SVN or CVS or GIT when all they really care about is a > particular defined workflow/client. Er, what is the difference in workflows between cvs(nt) and svn? I see that git enables radically different workflows but it doesn't even inhibit using it basically like cvs(nt). (Except for the by-file cherry picking.) > > 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; But that's not the fraction Tony was talking about that views version control as a necessary nuisance and just want to commit their work, and hardly ever do merges or even tags. Which is arguably the majority. The only real resistance I see is "it doesn't have an eclipse plugin". We have used cvs and then cvsnt, and started to think seriosly about switching to svn two years ago, and then still waited until svn 1.5 came out -- we didn't want to do without merge support. Neither have I looked into anything else. Only about the time we started going to svn I became aware of git, and by now that we are actually moving sources to svn I'm starting to find svn pretty stupid in all dimensions, and git simply much more handy. ... > A lot of people blame *tools* when the reason for certain limitations is > *policy*. Policies tend to be buggy and hard and slow to change. > 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. That's why I need to find someone else who is able and can be convinced to do the commit for me. But still, if I have the necessary change in my sandbox, and I can't move the change to my proxy using the version control system (and instead need to check that his sandbox has the same version checked out before I copy over that file (or files)), *that's* a failure of the tool. If I'm not allowed to commit a change, that does not mean that it is forbidden that I pass on the change to another person who is allowed, and the tool should enable me to do so. That aside, our svn admins are already complaining that the policy isn't managable anymore. > 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). ... > 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. That's again a policy question. There is not reason you should scrap your history, and there are people as well who, under cvs, don't commit their small changes at all. That's another case where the tool changes the way you work. Yes, you can start a branch in svn to do some experimental work, but it's work, and you can't just name it 'test', and in git it's so much easier that you actually start doing it much more often. (Ok, it still needs a developer who knows about this, and to overcome the feeling of good ole cvs that branch maintenance is hard work.) And by the way, you can just publish your git commit identifiers (which are SHA1 hashes) and thereby later prove that you had a piece of code or information at that time. > 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... On my laptop there are a few sandboxes that have uncommitted modification since before git was invented. ... > 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. No, I meant change of variable names in the source code. Darcs is strange, and not really one of the major players. ... > The real bleeding edge of SCCM is line/block revision control so that > the SCCM system can identify that all these projects have about() Where is that bleeding edge? So far I failed to notice anything like research in that area. I also heard claims that git can track moves of individual function between blocks but it doesn't look like it does. Andreas