May 22, 2013 at 4:18 am
I am at the whim of my clients. I can recommend, request as well as try to cajole but at the end of the day I am often not allowed to install software and certainly not allowed to create data repositories. The good news is that the vast majority of clients have used some form of version control for a long time now. I have often disliked the systems or practices employed but they are always better than nothing (and lets face it sometimes dislike doesn't mean they are wrong ;-))
Worst case scenario, I use a similar file scheme to Steve's (probably like most other people).
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
May 22, 2013 at 6:13 am
Is anyone using Continuous Integration with their Source Control solution?
Unit testing?
May 22, 2013 at 6:49 am
I have used Continuous Integration (CI) before and wholeheartedly recommend it.
Currently applying Test Driven Development (TDD) and recommend it too.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
May 22, 2013 at 7:18 am
We use VSS, and I'm in the minority of team that advocates it. I know there are better options, but I don't want to open that can of worms. The first sub-team I was on avoided using it, we just kept the two versions in regular disk space. When that manager changed, I checked that code in.
In the past, I have been a team of one, and I used VSS. If no other reason, the ability to take two versions and instantly find differences is invaluable.
May 23, 2013 at 10:58 am
Nadrek (5/20/2013)
For those using a "real" version control system: When was the last time you tested a restore of one of your CVS backups?
Excellent point.
June 17, 2013 at 3:25 pm
I've used a variety of version control systems over the years, including a couple of home-rolled ones back in the days when there were no useful version control systems. Most version control systems are horribly flawed in that they make no attempt to integrate version control and configuration control. When each developer is responsible for his own chunk of code (so that the semaphore effect of checkin/checkout is irrelevant) a very simple version control system is fine provided it hooks onto some sort of configuration control. For projects with fewer than about 30 developers, complex checkin/checkout can be just a pain - it may be better to work with a t-card system on an array of slots on a wall somewhere (open plan offices and low-wall cubicles have of course reduced the available wall-space so in many places the T-card version of checkin-checkout can't work). For really cooperative development (where the checkout semaphore is multi-pass) some sort of merge process is needed with checkin, and although there are several attempts out there to automate that I would rather do what I did back in the early days - have human beings handle the merge (with the aid of tools designed to help them, of course).
In my first job, we had no version control - and it didn't seem to do any harm; but we were doing research, not development. I left that job at the end of March 1969. In my second job I invented my own version control, because as well as research I was doing some development. after that there was always some sort of version control, although it varied from being a component of a very feature-rich development environment, ICL's CADES to something very simple like VSS. In my last permanent job, when I joined the company (2002) it used VSS for all C++, some JS, all HTML, and nothing at all for SQL or Flash. The only way to discover the current schema was to log in to one of the customer sites and get it to script every database - you had to know which customer had the latest version, but as there were only two customers at the time that wasn't too hard; I changed that rather quickly.
Tom
September 8, 2017 at 2:16 am
We used a product called PureCM, because it was the cheapest. At home I use it too, because the first two licenses are free. Simple, easy to install with merge control tools and much more.
5ilverFox
Consulting DBA / Developer
South Africa
September 9, 2017 at 6:27 pm
Looking at this editorial again, and the comment I posted four years ago, I see that I failed to say that this was an excellent editorial, which I certainly should have said.
I also failed to say that I regard not having all of ones code (including all the DDL for everything) in version control, and not having it seperated into fairly minimal units (each table's definition in a separate unit, instead of the whole datsbase s one unit) is either utter insanity or proof of insufficient experience to get it right.
Tom
September 11, 2017 at 5:50 am
I didn't chip in 4 years ago, so I might as well today. The editorial is as relevant as ever.
I put far more time and effort into maintaining our code and database schemas in version control than I gain from it. But to me, it's a principle.
It is, however, also a principle I am alone in my shop fighting for. Not that I experience that much opposition; the others just doesn't care about it, and they circumvent our VCS procedures whenever they want. So in short: Everything I am in charge of is version controlled. Everything else is not.
But the biggest thing for me is: I work in the cross field of IT and business. What good is it that our code is version controlled, when everything else (from policies and procedures, to budgets, annual reports, meeting minutes, work prepared and done in Word, Excel, Power Point, etc. etc.) is not? Because Version Control is great for so much else - both when you collaborate with colleagues and other contributors, and when you work on something alone over lengthy stretches of time. How many times have I not met the question "who changed the file last week? - and what change was made?"...?
Viewing 9 posts - 31 through 38 (of 38 total)
You must be logged in to reply to this topic. Login to reply