Re: Versioning control
Hi, Adrian:
On Wednesday 15 April 2009 10:22:00 Adrian Chapela wrote:
> Hello,
>
> I am preparing a versioning control. In my environment some of the
> clients are Windows PC. I have implemented the next Subversion +
> TortoiseSVN (for windows clients) + Eventum (for bug control, etc.). All
> work very well but I have a problem that I think it won't be resolved
> with any Versioning control.
>
> The problem is the next.
>
> User1 modifies file1 and file2.
> User2 modifies file3 and file4.
> file1, file2, file3 and file4 belong to the same repo.
>
> User2 has removed a function from file3 which is used by file1.
> User2 has tested all of his changes and all of them work well.
> User1 has tested all of his changes and all of them work well.
> User1 commits all of changes.
> User2 commits all of changes.
>
> Now the copy on the repo is bad
Section 1.2 of the CVS manual is very enlighting:
"1.2 What is CVS not?
CVS can do a lot of things for you, but it does not try to be everything for
everyone.
[...]
CVS is not a substitute for management.
Your managers and project leaders are expected to talk to you frequently
enough to make certain you are aware of schedules, merge points, branch names
and release dates. If they don't, CVS can't help.
CVS is an instrument for making sources dance to your tune. But you are the
piper and the composer. No instrument plays itself or writes its own music.
CVS is not a substitute for developer communication.
When faced with conflicts within a single file, most developers manage to
resolve them without too much effort. But a more general definition
of “conflict” includes problems too difficult to solve without communication
between developers.
CVS cannot determine when simultaneous changes within a single file, or across
a whole collection of files, will logically conflict with one another. Its
concept of a conflict is purely textual, arising when two changes to the same
base file are near enough to spook the merge (i.e. diff3) command.
CVS does not claim to help at all in figuring out non-textual or distributed
conflicts in program logic.
For example: Say you change the arguments to function X defined in file ‘A’.
At the same time, someone edits file ‘B’, adding new calls to function X
using the old arguments. You are outside the realm of CVS's competence.
Acquire the habit of reading specs and talking to your peers."
See?
At the root of your problem is that you layed down "tools" without regard
to "processes".
> , because the User1 is using a function
> which isn't on the file3 commited by the User2. Is there any way to
> advice User1 that some other files are changed by another user ?
The best approach certainly is proper good comunications (you posted the
easiest way to go into a "semantic conflict", but without proper good
communication and processes in place you will find other much subtle cases).
Anyway, for the tool at hand, yes; it's possible to have a "post-commit hook"
(basically, an script; you will find some templates on your repository under
the "hooks" directory) that will do anything you ask, like sending e-mails or
IM, backuping the repo or anything you can think of.
> I know
> that the User1 should update his working copy before commit their
> changes but theres is another situation which end in a problem.
No, no, no. User1 should *talk* to User2 regarding that API change and how it
will affect distant code; thus they will be able to serialize their work and
the change from one won't be surprise to the other.
> After changes:
> User1 updates his working copy.
> User1 tests his changes. All work OK.
> User2 updates his working copy.
> User2 tests his changes. All work OK.
> Then User2 commits his changes at the same time that User1.
> Subversion will accept the changes because all of them are of different
> files. Then the commited code are wrong because the file1 is using a
> function which isn't in file3 now.
>
> Do you have any idea to solve this ?
There's no way to do it in the real world. If there were it could be used for
bug-free programs. No tool will have so deep understanding of the code under
development to avoid all such situations, nor it would be desirable to do so
(just as you can already go for formally tested code, but you won't want to
except for extreme cases).
But you can work on *processes* to keep good ballance. The lowest hanging
fruit is already bespoken: your development team must talk, talk and talk.
This way it wouldn't happen that someone's API change will take others by
surprise.
Test driven development. This way these kind of mistakes will be fastly
discovered if the "talk, talk, talk" phase fails.
Automated build procedures. This way you will have a "dumb" member on your
team that won't give anything for sure.
Proper architecting you app. This way you encapsulate functionality so what
an API change means and its reach is minimized (thus the expenditure in
the "talk, talk, talk" phase).
Think on processes and then allow the tools to achieve your goals. Again,
your SCM tools are "not a substitute for management" nor "a substitute for
developer communication".
--
SALUD,
Jesús
***
jesus.navarro@undominio.net
***
Reply to: