Hot answers tagged

6

I'd say, do not bother with the old snapshots. Commit current state into the repo and start using it as soon as possible. Just backup the old snapshots and in a couple of month you will not even remember they've existed. From experience, when we migrated from CVS to GIT, the old CVS source control was left there for reference, but after a few month nobody ...


5

Tight coupling, lack of testing, these are probably the most common culprits. Basically the issue is just shoddy standards and procedure. Yet if you work in a very large codebase, I would add one common one which can occur even with looser coupling and greater care to testing procedure. The Side Effects of Removing Parasites Codebases evolve against their ...


4

If it fits, it works. Quite simply, the people who came up with the first version of the equation took a whole bunch of projects and looked at how much effort (in terms of man months or years) was put into the project, and how much time it took to produce the product. And then they fit it to a curve, and thats the numbers that came out of the data. From ...


3

What you have there is version control. I think we can all agree that it is a pretty crappy form of version control, but you at least do have different versions, even if you don't have commit messages. Why throw away that history? From what I can gather from your description, it's a three-line script and a matter of minutes to import that history into a ...


2

If you only have to update/patch/support a single version, then just starting the repository with your last version is a perfectly good idea. Keep a backup of the old versions, just in case, but I'd expect it to be unlikely you'll need it. However, if you have to support multiple versions of your project, I would recommend making a commit per each of the ...


1

The single best thing you can do is introduce some standards. Everything you say is caused by a mess of "do whatever" appearing in the codebase. Keeping this concept of "add some more cool tech (eg EF migrations...)" will only add to the problem. You need to reduce the scope of maintenance, not increase it. The best way to do that is to start to reduce the ...



Only top voted, non community-wiki answers of a minimum length are eligible