Re: Versioning control

[marc <gmane@auxbuss.com>]

Adrian Chapela said...
> 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.

So you have deficient tests or a deficient testing process.

Also, before deleting a function, since this clearly has potentially to 
do damage, I would expect a prog to check that it isn't used elsewhere. 
Modern tools have the equivalent of "Find usages", which makes this 
simple.

> User1 has tested all of his changes and all of them work well.
> User1 commits all of changes.

> User2 commits all of changes.

As you note below, User2 should update before committing - that's not 
optional with svn, right? Seeing changes, this should trigger an action 
to retest before committing.

In any case, after User2 commits I'd expect your CI tests to collapse.

> Now the copy on the repo is bad, 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?

On Windows there's a neat tool from the tortoisesvn guy called Commit 
Monitor:

  http://tools.tortoisesvn.net/CommitMonitor

You shouldn't see this as a fix to your problem though, which looks like 
a testing problem to me.

> I know 
> that the User1 should update his working copy before commit their 
> changes but theres is another situation which end in a problem.
> 
> After changes:
> User1 updates his working copy.
> User1 tests his changes. All work OK.

With a missing function? Surely the tests should break.

> 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 ?

Yup, improve your testing. You don't need 100% coverage, but you need to 
exercise each function.

-- 
Cheers,
Marc