On Thursday, February 17, Frode Nilsen wrote:
> Tobias Weingartner wrote:
> >On Wednesday, February 16, Frode Nilsen wrote:
> >>
> >> There are two situations that makes this "mess".
> >> 1. The developers are situated at different sites, working at different
> >> times etc.
> >
> >I've worked with people on projects all over the world. This has *never*
> >been a problem. Not ever.
> >
>
> Lucky you.
> Have you known who each and every developer was ? From graphical design to
> (beta) testers ? so you could inform them about which file that must not be
> touched at certain times ?
Huh!?! Lucky? I've been on the bloody net, working with people since the
mid-eighties. I've been working with some version of CVS for almost that
long (I remember the "original" shell scripts...) Why tell people that files
must not be touched? On mergable files, this should not be a problem. On
files that are not mergable, 1 person is responsible for commiting the file.
> >> 2. Some of the code are libraries that no one thought anyone else was
> >> working with, but they needed a quick improvement.
> >
> >Here is your problem. These "quick" improvements tell me that you do not
> >have any management structure within your developers. It's basically a
> >"free for all". While this may work in some environments, it usually causes
> >duplicated and wasted effort. Communication *WILL* solve this, locks will
> >not.
>
> When you have to get a fix out to your customer within 24 hours, this is
> the way to do it. Other developers are informed about the changes after
> they are done.
And if another developer has that "library" locked, you break the lock, to
get your fixes out to the customer within 24 hours? So locks will not help
you with this...
> And yes, I know locking won't support this, but it will inform the
> developer what problems he is causing and he can solve it at that moment.
> Not a week later when the first developer tries to incorporate his version
> 2.1 of the library.
Huh!?! Again, communication will solve this. The manager tells the developer
that this or that needs "solving/fixing", right now. Part of the "hiring"
agreement is that fixes of a certain type need to be done within 24 hour period.
Also, one of the most important things I've always been teaching, is "update
often". This is both to keep things in sync, and keep you uptodate with what
is happening in the rest of the tree. The more often you update, the easier
conflict resolution tends to be, and the sooner you know about any conflicts
starting to occur.
Also, being on an e-mail list from commitinfo, a list which simply e-mails the
list of files modified plus the commit message, goes a long way towards keeping
everybody informed what is being worked on, and what has changed. So much so,
that updates can be done in a fairly intelligent manner, instead of simply "often".
> If you think communication will solve this, why do you use a concurrent
> version control system at all ? It is design to let you forget about
> communication !
You've missed the point of recent discussion so far, that left field is not
within this local sector of space anymore.
> >> That is true, but as always, real life is not so simple. The code stays
> >> this modularized for about 6 months, then bug fixes, new features etc.
> >> makes their way in and mess things up until someone says 'Hey we need a new
> >> design for this solution' and then after 6 new months your code are
> >> "correctly modularized" again.
> >
> >Exactly why managers are paid more. If you have a "mess", your managers
> >are not doing their job.
> >
> Sorry, but at our shop the customers are getting their solutions on time.
> What a developer are considering as best practice has no importance.
Wow. May I ask how the general model goes? IE: developer A is "responsible"
for library A. A customer comes along with a problem, and it is traced to
library A by developer B. What does developer B do? Communicate with A (who
may have a fix already in his sandbox), or "simply" fix code he is not really
knowledgable about, causing duplicate effort to be exerted?
> This is getting out of topic.
> I just described why I needed locking. We are not going to change our
> development practice because yout think it is bad.
In a lot of people's opinion, you've just described a reason for more concurrancy,
not serialization and locking. Your development practice may be very good, esp.
if you are getting the job done on time. However, I'd question your communication
and management practices...
> If CVS doesn't support locking (in the future) we have just another item on
> our list why to choose another system.
> If we do this change I IMNSHO think that would be a shame for CVS and the
> Open Source Community, because it shows that it realy isn't that open.
Sure it is. Is your software freely available for me to browse, and see what
sort of coding practices, code organization, and other structure there is
within it?
Open does not necessarily mean that it is "bend to the whim of the masses".
--Toby.
