Tag Info

Hot answers tagged

20

I think that it adds value even in a single person starting project. The earlier you set it up, the easier it is, and the less time you will have to spend during more crunch times worrying or wishing you had it. Even from the start it will make sure that all unit tests (even if there is one) will get run as often as code is checked in. Otherwise you rely ...


19

Also are there any pros and cons of using any of them? Registry: + Relatively standard in the Windows environment. + Generally good support from installers, etc. - Platform specific API, if you ever want to port your application. - Not particularly human readable. INI Files: + Simple format. + Portable. + Human readable. - May be difficult to ...


17

Wikipedia has a discussion of various version number schemes. It really doesn't matter what scheme you use, and your customers probably don't care. The key is that you can identify the version that is being tested or has been released and have quick access to all associated artifacts for that version.


15

I'd go with INI files, they are the more human friendly option: [window] width = 600 height = 350 position.x = 400 position.y = 200 [paths] path1 = "/some/random/path/" path2 = "/some/other/random/path/" [user] name = "Yannis" preference = "INI" XML might be a good option, but it can't beat INIs' simplicity and elegance: ...


14

Though you already got some good answers here, most of them miss the root cause of your problem: your user config files seem to contain more than just user-specific information, they also contain (perhaps redundant) information which is under version control somewhere else, probably in different files, like module names. I can think of two possible ...


13

IMHO, it is always worth the trouble. Even if you don't have a single unit test and the integration is nothing more than checking out the project and building it you are still coming out ahead. If your CI build succeeds it means any idiot can check out your code and build it. This probably puts you ahead of 85% of software projects on planet earth. I would ...


13

Most applications will require some external configuration; you can hide this by making it dependent on magic variables, or by saving it to some internal location, but that won't remove the need. The goal is to recognize what should be external, and what can be internal. Only the internal parts can be tested. An application should not trust an external ...


12

tags, branches, merging IMO these are basic functions of any decent VCS, not particularly advanced features of Git. I suggest reading some of the excellent online guides such as: http://gitimmersion.com/ http://progit.org/ http://gitready.com/ http://book.git-scm.com/


9

Remove documentation for the feature; Disable interface for the feature (hide menu items or remove an option from a console command). Everything else is way too dangerous.


9

Spoike's answer is excellent, but there are a few things I think it would be worth adding which are too large for comments. Branch organisation With Mercurial you can happily ignore the whole of your first organisational chart. As Spoke says, each repository has it's own set of tags, branches (named and anonymous) and can be organised according to business ...


8

Okay, trying to answer this simply. What you need to know First thing you need to know: Mercurial is distributed version control and has some properties you should know about listed below. The source come from one repository, where that repository can be cloned. All cloned repositories can share code with each other through synching (with pull and push ...


8

It's a reasonable solution. You need a way of specifying the initial value(s) of any new configuration element(s). These have to be stored somewhere and a global, read-only, configuration file is the obvious choice. Then when each user changes their personal configuration you write these changes to their local copy. Your code will need to read the global ...


8

I agree with MetaFight, this is a tough one. Just to throw out a contrarian view point, do you really have to merge the code? You have two large blocks of code that share a common ancestor. They split off from each other at least 3 years ago. The blocks have been maintained by two independent groups who apparently don't talk to each other. What value ...


7

One standard I find amazingly useful is the Semantic Versioning Standard at http://semver.org . It's really short, but straightforward and I haven't found an issue yet that it doesn't cover.


7

In a large organization that does best practice software development the development infrastructure is the domain of IT - as it should be. These servers are usually locked down just like any other server, and developers do not have root access to these machines. (Would you give the Office Admin root access to the corporate email server) IT will have an SLA ...


7

Configuration (information about the environment required to do work) Create a configuration class (to be picky: an interface + an implementation) which purpose is to provide the information about the environment. This makes the configuration in no way different from other objects required for your object to do work (point 1). Parameters (Data that ...


7

I am not a Scrum expert, but AFAIK "collective code ownership" is meant to be per team and per product (and I think your question is not specific to Scrum, it could be applied to any "shared code" development process). If you have two teams, two products A, B and a shared component C, there are different possible scenarios. Maybe the shared component ...


7

There's nothing "agile" about a 3-year merge. Your team is going to have to put "agile" aside for a while, probably considerably more than a single sprint. You're going to want to freeze current codebase before you merge and extensively test, so you'll know that the starting code is fully functional. Then you're going to have to do the full merge, ...


6

My previous employer sells some software that enabled different features based on the particular license involved. So the ability to enable/disable features at runtime was a designed in feature. Generally, folks call this "feature driven development" (wikipedia article, decent book on the subject). It requires a lot of testing to find bugs that can be caused ...


6

Learn the core first: If you take the time to understand how git works, then you will be able to easily understand all of the advanced things you can do with it. But let me emphasis: if you do not learn the core structure of git, all of the advanced things will be "black boxish" and confusing for a long time. A brief explanation: At the core of git is a ...


6

My preference is XML files. They are hierarchical, you can bend them to your will in almost any way imaginable, they are well understood, platform independent, and there is a wide array of software available to read and write them.


6

To expand Jeff D's suggestion of YAML, here's a brief intro. YAML is similar to JSON (in fact, JSON is a subset of YAML since version 1.2 of the YAML standard, and can thus valid JSON can be parsed by YAML parsers). At first glance, the main difference being that YAML (by default) uses indentation rather than bracketing to show hierarchy. There is also a ...


6

I would classify them more as a "known problem area" than an antipattern. Unless you are going to deploy a fixed configuration, you'll have to store configuration information somewhere. I usually like to store most of my configuration information in the database, but you still have to store the database connection information somewhere. I do prefer the ...


6

(in my experience) Major decisions (especially involving product owners) belong in design documents. Trivial technical decisions (why is is field empty?) belongs in a comment right next to the field. In between sort of decisions are odd. I tend to think that undocumented communal knowledge is best, since documentation of a decision is useless if nobody ...


6

This is a tough one. Having to merge two branches of code you're unfamiliar with is tough to begin with. Add 3 years of divergent development and you've made it something I would quit my job over ;) But let's be constructive. There is no easy solution for merge conflicts. You'll have to resolve these manually. And, unfortunately, with every merge ...


5

There are many other pressures: Writing a config file requires write permission on the file system (in fact, it requires a file system in the first place!). Environment variables can be set even if you are running a rescue system from a CD. Environment variables can be set quickly and temporarily just for one invocation, which is much better for use in ...


5

External configuration files are NOT an anti-pattern. Like everything else they can be used well or poorly depending on the system in question. You seem to have run into some apps where the external config can break the app without telling the user what's going on. That's bad, but it's not the fault of the config files, it's the fault of whoever decided ...


5

Sounds to me like it could be a big mistake to to treat this as just a big example of a merge, something that is going to involve an unusually long set of sessions sitting in front of a merge tool and pressing 'accept/reject changes'. Instead, I would: Spend an appropriate amount of time, perhaps a week, reading both sets of code. Decide which one has ...


4

I would never write code such that features are switchable on or off -- unless that requirement was made up front. Removing or disabling a feature is a change to the specification, and just like any other specification change, requires time to implement and verify. You need to ask why the feature is going to be excluded - is it still too buggy to be ...


4

We had a similar problem at my work. We solved it by not using the config files. We wrote the things that when changed required a code change any way in code, and then moved the rest of the properties to a settings table in a database. We wore able to do this because we control every server we deploy code on. This change simplified our systems drastically ...



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