OPENCORES.ORG

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@o... [mailto:cores-bounces@o...]
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