|
This sounds more like a workflow issue that svn (nor git or mercurial, for that matter) can completely. If anyone can deploy to test at any time and potentially blow away someone else's changes, you're going to run into issues. What would help would be for developers to do something like create a git branch fro whatever feature they're working on. That way, at least they'll still have a local copy of whatever they were working on in case someone else overwrites it on the test server. Git branches are cheap. Even with svn, though, there's not much excuse for losing changes because you pushed them to a remote server and then got rid of your local copy.
Perhaps begin with a policy that developers can never, ever, push something straight to the test or production server.
Set up a CI server like TeamCity that will run your build and run all tests whenever someone checks code in. Set up TeamCity to automatically deploy to the test server once a week (or whatever time interval works best for your team). Make sure all developers know when this happens, so they'll be able to commit/push their changes in time. Create a tag or branch in source control representing the build that has been pushed to the test server.
Once the build on the test server has been running well enough on the test server and you're ready to deploy it to production, grab the correct version from source control (easy since you have a branch or tag for it) and deploy it to production.
|
|
|
|
|
The simple answer here, I think, is to check in your code when you change it, and not after it has been through the test server process. If it fails testing, you need to fix it, check changes in then submit to test server - so everyone is getting the latest version of the source most of the time, rather than having long delays between getting code and updating.
though I'm not sure what you mean by 'test server' in your context - are you pushing code to the test server before checking it back in to SVN?
PooperPig - Coming Soon
|
|
|
|
|
Basically, we get latest from the svn and then dev A works on it and pushes to test server directly and not to SVN. Once bugs are sorted and is a stable version, then dev pushes it to SVN and to production server.
I am going through all the suggestions now and see what can work for us.
Thanks
|
|
|
|
|
Get them to pay for a consultant for a couple of weeks. I've recommended this at a couple of gigs and it worked really well (TFS). It was well documented as a bonus so well worth the outlay.
|
|
|
|
|
SVN is not a substitute for brain or basic human decency. It simply wasn't designed for that.
it ain’t broke, it doesn’t have enough features yet.
modified 20-Oct-19 21:02pm.
|
|
|
|
|
Kamen Nik wrote: SVN is not a substitute for brain or basic human decency. It simply wasn't designed for that.
Crikey - was it not?
|
|
|
|
|
Anyway, what I would do is, make some rules:
- every class - separate file
- class with more then 10 methods - refactor
- methods with more that 30 lines of code - refactor
- assign them to work on separate tasks and commit/merge at the end of every day in a test repository.
- Production version code in a separate repository
it ain’t broke, it doesn’t have enough features yet.
modified 20-Oct-19 21:02pm.
|
|
|
|
|
I can't speak to GIT. I haven't used it other than playing around. But we do use SVN. I have tried to keep the developers from working on the same code and that has worked pretty well. The one big problem we have is with the dbml files for Linq. And really what is required is communication between developers. It is almost impossible to manage changes through SVN. We normally revert then make the changes then commit. It can be a pain when more than two have modified the dbml.
As long as they are talking and they stay out of each others code, which is easier said than done, SVN is working really well for us without all the extra features.
We are using both TortoiseSVN and AnhkSVN. AnhkSVN has some issues with updating the code when there are conflicts but TortoiseSVN works great.
Jack of all trades, master of none, though often times better than master of one.
|
|
|
|
|
We are a team of almost 100 developers working on the same code. We use git and merge seems to work well in most cases. We do not use a test server because of problems that you describe. Instead we schedule regular 'stability points' that serve as snap shots and used for testing etc. A few days before a stability point, we are asked not to push any major changes while a few team members do some simple testing and fixing before releasing the build for major testing/customers etc. Anything major is then fixed in the stability branch and cherry picked over to the main branch. It is not ideal but it seems to work acceptably especially with so many developers working on the same code base.
Of course, our code is for embedded systems and so it is a little different to what you describe.
|
|
|
|
|
SkysTheLimit wrote: we schedule regular 'stability points' that serve as snap shots and used for testing etc
Sounds good but where do you test these stability points? At local or development server?
|
|
|
|
|
We make a separate git branch for each stability point and deploy the code to several development benches for testing. One challenge of doing it this way is that some things that are found in a stability point may already be fixed in the master branch and so it takes a little extra time to go through the issues to verify that's the case. It also means that you may end up fixing the issue in both branches but with git, the cherry-picking seems to work quite well.
|
|
|
|
|
A couple of years ago I was in exactly that situation, except even worse.
Some projects were in SVN and some even in CVS.
Branching and merging wasn't something you did, if you had something planned for the weekend next month.
So I did some serious research over a longer time and came to the conclusion that what we needed was a distributed version control.
This is for several reasons, but one the main ones is that as you have a local copy you can commit to as often as you want, and step back to earlier versions of the code without affecting other developers.
And then you only push working code to other repos.
Secondly, merging works. Really!
The two leading systems are GIT and Mercurial, and of those two I ended up choosing Mercurial, despite Git having the momentum.
One of my reasons: While Git is more powerful and has more plugins, it is also less homogenous and has a steeper learning curve than Mercurial. Obligatory xkcd reference[^]
And as far as I understand, the main reason Git has the momentum is because Linus Torvalds chose it for Linux, and his main reason was that he could rewrite history using the Rebase plugin that didn't have an equivalent in Mercurial at that time citation needed
But it also requires a change of mindset. When using a DVCS you're really supposed to work with branches. Have a look at Hg Init: a Mercurial tutorial by Joel Spolsky[^] for a really good primer.
Mercurial also integrates really well with SVN, just install the HgSubversion extension and you can keep on using SVN if you'd like, while having a local clone of the repository working with Mercurial.
BTW, the simplest way to use it is to simply install TortoiseHG and integrate it in VS with VisualHg
|
|
|
|
|
Git is probably a better tool if you want to branch and merge back easily. SVN can do that too, but the process is a bit more laborious.
However, if your team can master the art of branch/merging then you would be able to set up a dev/test/live branches, which in turn can be split into further sub-branches. e.g. changes associated with a single CR will be branched from dev.
The person responsible for configuration management will manage what specific branches merge onto the main branches. Then the dev master branch is propagated to test and then test to live. Because your developers work on their own branches, they should never need to lose their work again, and if a merge goes badly it should be easier to undo it.
You should also review how your code is structured, both in design and on file. If you have only two developers treading on each other toes it may be a symptom of design issues within your application.
modified 22-Mar-16 5:56am.
|
|
|
|
|
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
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
