1. Can you give some examples of commercial tools that are still only lock-modify-unlock? I am not too familiar with many commercial options, but doing some quick checks on google, many of the commercial options I can find have switched to the copy-modify-merge, and the lock-modify-unlock is generally considered outdated, causing more problems than it helps. In general, I think most developers will agree that LMU slows development, and is not appropriate for large teams. 2. Personally, I think your scenario would work well with git, although it would allow other developers access to each others files. IMO, blocking access to files that are controlled by other developers is a big source of bugs and poor quality control. Instead of finding and correcting a problem in someone else's files and uploading the changes (which the owner then must approve), the developer ends up working around the problem, causing duplicate code, extra dependancies, etc... Even if the work around is fine for "now", because it wasn't corrected where the problem really was (that file was LOCKED and the code isolationism decreases communications), the problem will show up again... CMM promotes communications because the developer will know when their files are modified by someone else. 3. Easy... The owner of the code can back-out or require review of the changes prior to accepting. I think Linux and many other open source projects is proof that it can work. The 1000 line limit also sounds a little short, but what is reasonable also depends on the language... -----Original Message----- From: cores-bounces at opencores.org [mailto:cores-bounces at opencores.org] On Behalf Of Richard Tierney Sent: Tuesday, April 18, 2006 4:50 AM To: Discussion list about free open source IP cores Subject: Re: [oc] kindly convert opencores cvs repository to subversion (svn) . . . 1 - Why are commercial tools lock-modify-unlock, rather than copy-modify-merge? Can you name a proper commercial tool that uses copy-modify-merge? Why is this? 2 - Imagine you're a project manager with say, 20 developers, each of greatly differing experience and ability, and each working on 100 source files. How do you set this up? I'll tell you how I would set it up: each developer owns their own source files. They're responsible for those files. The other developers cannot get arbitrary access to those files. A developer carries out the requried changes to their own files, except in exceptional circumstances, such as code reviews, holidays, and so on. 3 - the whole concept of merging different changes into a software source file is just bizarre. The whole file should ideally be about 400 lines long, and certainly no longer than 1000 lines. One person needs to understand the entire file intimately. How could you, as the project manager, possibly allow two different developers to simultaneously modify two different parts (or, in the worst case, the *same* part) of the same file? I've worked in one commercial environment where we used CVS. This worked because we agreed on the rules above, so merging was not an issue. This is fine, so long as everyone knows their place. I've worked in another environment with a commercial RCS-based tool (in other words, lock-modify-unlock). This worked because it couldn't fail. Take your pick. As I said, I'm talking about real-world commercial development; web development of free software could be seen as being different. RT _______________________________________________ http://www.opencores.org/mailman/listinfo/cores