|
It sounds like you are using your test server as the integration point rather than your source control system.
Source control should be your integration point, and when a new test is desired, push from source control to the test server.
An automated build process (extract from source control, build, push to test server) might help.
It's a fundamental workflow problem.
Software Zen: delete this;
|
|
|
|
|
I think this is the heart of your issue. It's not the tools but how you are using them.
- All changes should be checked in before they go to test.
- Test (and Prod) should be always be built from some specific SVN revision.
- You probably could use a branch for what's in prod where quick fixes can go and another branch or trunk for the next big release. You'd have to merge prod fixes to the release code. And you might want a dev server to "test" the bigger changes on.
Something like that...
|
|
|
|
|
A lot of good info in other posts.
Here are some other thoughts:
Some VCS systems perform conflict resolution best if each developer works on their own private branch and merges to the pre-production branch.
Test server has a single pre-production test area that no developer can update! (repeat recommendation)
Pre-production should only be updated by refreshing from your pre-productin/"head" branch in source control or pushing from an admin VCS area where zero development occurs. (automate this!)
Each developer should have their own sub directory/virtual directory, application server, IP address, entire test server (cloned VM), server on their development box, etc. where they can host their own version of reality without stepping on another developer if they are working on the same files. VCS should handle the merging/integration.
|
|
|
|
|
There's a lot of good advice in this thread. The only thing I will add is instruct everyone to save a local copy of all changes made.
Protecting your work, even when using a revision control system, is a 100-level rule everyone should follow. Trust nothing, servers can fail or be damaged, backups can be unrestorable. Everything will fail, eventually.
No one with a lick of sense should get burned twice by losing their work.
|
|
|
|
|
Are you the leader of this team? If so then first talk with your people and together find a solution.
Choose one tool and learn it to heart. Do not skimp over a one page blogsite tutorial. Get a book or a course and take the time to learn it.
Backup all your code and start trying the tool, do changes, test it, break it. Do this as a team and learn together. Don't say you don't have time for this. You will lose MUCH more time if your don't learn your tools.
Then start using it as a team. When someone has doubts get together and solve it as a team. If someone doesn't understand the tool, get together and teach him/her.
Go for it dear leader!
|
|
|
|
|
cp-andy wrote: But our team has now increased and quite often two developers end up over writing each others code.
I seems that you have a problem with the partioning of your codebase.
Try to identify the hot spots and refacture it (smaller classes, more source files, apply well known design patterns)!
Watchout for source code files with many bugfixes and files with too many lines of code.
Changing your version control system doesn't help if 2 or more developers make large changes on the same files.
Git (or any other version control system with 3-way-merge) can only merge small changes automatically.
|
|
|
|
|
Thanks everyone for very informative replies. I will be doing some RnD on the basis of your suggestions and hopefully will find one solution.
|
|
|
|
|
So on Friday night I was on my home from the pub when a car pulls over and asks me directions to the British Legion (we were right outside it). A mixture of the dark and the drink meant I couldn't really see the guy behind the wheel but as he pulled away I realised the voice was Frank Bruno (I knew he was doing an appearance there but hadn't realised it was that particular day). So I followed his car into the car park and had a chat with him when he got out. Told him what a legend is and how I had wanted to go see him but didn't have a ticket (they were £50). He said don't worry about that pretend your with me. So I did. Walked in with him and spent the night in his company without paying a bean.
Diamond geezer. Still can't believe it actually happened. Probably one of the best blags I've pulled.
|
|
|
|
|
|
|
|
I would say that that also applies to anyone who believes that JavaScript has any good parts.
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack.
--Winston Churchill
|
|
|
|
|
The top one should be a pamphlet.
|
|
|
|
|
"The Pamphlet Is A Lie"
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
More like a PostIt with a VERY LARGE FONT
veni bibi saltavi
|
|
|
|
|
Have you seen the Bonus here: What. The. Elephant?[^]?
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
Figurative artwork? (8,2,7)
I am not a number. I am a ... no, wait!
modified 21-Mar-16 6:57am.
|
|
|
|
|
|
Yup! She's all yours.
I am not a number. I am a ... no, wait!
|
|
|
|
|
Movie Quote Of The Day
He's a lot like meself, but absent me merciful nature and sense of fair play.
Which movie?
|
|
|
|
|
Winnie the Pooh
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
The one armed Bandit
Rules for the FOSW ![ ^]
if(this.signature != "")
{
MessageBox.Show("This is my signature: " + Environment.NewLine + signature);
}
else
{
MessageBox.Show("404-Signature not found");
}
|
|
|
|
|
The Sweeney
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack.
--Winston Churchill
|
|
|
|
|
Kinda me, but ain't
|
|
|
|
|
That stupid Canadian artist
In Word you can only store 2 bytes. That is why I use Writer.
|
|
|
|