One commit, multiple people.

I have two programmers, Bob and John. They both work on the same probject.    They each develop code on their own machines, but share a testing server to test the php scripts.    Right now they are not committing individually to SVN, but rather, together at the end of the day. This means only one person commits for the both of them.    Something doesn't sound right here so I asked them about it and this is what they said.    Suppose Bob makes a change on b.php during the day, and John makes a change on j.php. Bob will upload b.php to the test server, and when John finishes editting b.php he will upload that also. Since both get the freshest updates they don't have to do a run-around, where they have to commit to SVN, then update, just to receive the other person's changes.    So, at the end of the day, all the files are the same on the test server, and they update that.    The alternative is this... Bob makes a change to b.php during the day, updates SVN. John would then need to update his SVN. This would occur multiple times throughout the day and is a hassle.    As for file consistency, they said phpedit already checks your changes against the file on the server. If it was changed by someone else in the meantime you'd get an error about it, so that's not a problem.    So my question is, what do you think of the way they're doing it? I don't like it because now one person commits on behalf of another. This means it's never clear who did what at what time.

Last updated 16 years ago

You've really answered your own question, and I agree with your answer. You start by saying you have two programmers. If that's accurate, they should work according to your desires, not theirs.    Some additional comments and observations.    Since they are working on different files, they wouldn't each have to update their working copies after the other commits. Once a day would suffice.    Isn't uploading after each file change a 'nuisance', too? They willingly do this, they could update, too.    Here

when John finishes editting b.php he will upload that also

I think you mean j.php. If so, it's another indication they are not clobbering each others files. Even if they were, SVN would tell them.    I would insist they commit their own files. YMMV.

Cut off their access to the test server. They're using the system wrong. I kind of question why they even bother checking into Subversion if they're working like this (I mean based on how they do things - I'm not questioning your use of Subversion, nor do I think you're wrong in thinking their usage is weird - it is).    phpedit may tell them when someone else has edited a file, but I bet it won't merge for them or find conflicts.    Each developer should have his own sandbox to code & unit test within (either a virtual machine, virtual host on a development server, or by having a complete runtime environment on their desktop). Once his tests have passed, he checks his changes into the repository, then integration testing can be done on the test server (install a post-commit hook to update the test server after each commit, or appoint a release manager to deploy changes as needed).    As has already been noted, the way things stand now, you have no record of who did what, and when - one of the many benefits of using any version control system. If Bob breaks things in the middle of the day, you have no way to roll back to anything other than yesterday's checkin, possibly losing several hours of work. If you ever need to generate a detailed changelog, or produce a history of the project for auditing purposes, you don't have that.

I totally agree with the above posts, and I would also add...it's not as much of a "run-around" as they're making it out to be.    The principle is that you should only be committing code that is worth sharing. So once you've completed a task and the code has passed its tests, you commit it. That's not a run-around at all. That's keeping your broken code to yourself until it's ready for others to incorporate.    The principle around updating is less clear-cut and is usually a judgment call, but maybe they are spending too much time updating? Your working copy can usually afford to be a little out of sync. As a general rule, I would say that the developers should at least update before testing and often before starting development of a new task.    And like andyl said, they're using svn wrong. It's not meant to save their state "at the end of the day". It's meant to help developers share code in an efficient manner.

(ode$lingerThe principle is that you should only be committing code that is worth sharing. So once you've completed a task and the code has passed its tests, you commit it. That's not a run-around at all. That's keeping your broken code to yourself until it's ready for others to incorporate.

   One more comment on this. The standard rejoinder is typically "Well, what if they're working on changes that are mutually exclusive or dependent? E.g., both working on b.php, or one working on b.php which depends on changes the other is making to j.php?"    The answer to that is "communication". VCS systems do not mean that your programmers no longer need to talk to each other.

I'm wondering, if this practicable:    

 The principle is that you should only be committing code that is worth sharing. So once you've completed a task and the code has passed its tests, you commit it.

   When I code some days to test a new algorithm, I've a lot of intermediate states. Haven't I  any chance to version it? Is this a kind of extreme programming (only check in what is tested)?    Thanks,    Steffen

SteffenNetzI'm wondering, if this practicable:    

 The principle is that you should only be committing code that is worth sharing. So once you've completed a task and the code has passed its tests, you commit it.

   When I code some days to test a new algorithm, I've a lot of intermediate states. Haven't I  any chance to version it? Is this a kind of extreme programming (only check in what is tested)?    Thanks,    Steffen

   No, it's actually just good practice. When working on the trunk only commit things that don't break other people's projects - unless that is the whole point of your fix (the API changes and you want to force them to start using the new code).    To do what you are describing, you usually create a branch. On a branch you can break your code as much as you want, and even commit in intermediate states. After you code "works", you merge it back into the trunk.    Cheers, Mike5

SteffenNetzI'm wondering, if this practicable:  

 The principle is that you should only be committing code that is worth sharing. So once you've completed a task and the code has passed its tests, you commit it.

 When I code some days to test a new algorithm, I've a lot of intermediate states. Haven't I  any chance to version it? Is this a kind of extreme programming (only check in what is tested)?  

 When I wrote that I was addressing a different issue, so let me be more specific about this. Subversion (or any source control for that matter) is not first and foremost a backup tool. It is a communication tool that allows you to share code.    If you want to use source control for backing up your intermediate (broken) code, I would agree with Mike5's recommendation that you need to create a branch. But I would add that you should make it clear that your branch is a personal branch.