Tag Info

Hot answers tagged

20

I've been in very similar situations (in the aerospace and automotive industries). Don't expect to progress very far in this or subsequent meetings. Both of these situations outlasted my desire to continue fighting for improvement, but here is the best tactic I've seen so far... You say "this process has worked for 20 years", but has it really? Start by ...


13

It works fine if you stick to the simple cases, but there are some complex ones that don't. The limitations I can think of: It can only find the most recent ancestor if it is on one of the branches involved. So if you create branches/this and branches/that both from trunk and then try to merge branches/this to branches/that, it will not know what to do. ...


12

Our production release process is a nightmare because it revolves around Clearcase. We have a change management group who executes all releases and who will only allow code into production that was taken from it. No, your process is a "nightmare" because of your change management group and your release procedures. Go ahead and replace Clearcase ...


10

I have a simple counter question for you: what do you want to do with those? Personally, my take on this is if it's a hobby, you should do only what is fun for you. Nothing else. If it spells work for you, or a big time investment, then just forget about it. You should not think of these projects as a sort of failure in any way. I have dozens, maybe ...


5

Specific examples will impress more than abstract advantages. I think you will find most success if you can document particular examples where (a) Clearcase caused problems that took time to solve and (b) Git solves those problems. Remember that you don't need to go into technical details of why this is so (unless asked) simply show that it is; management ...


3

How about compile time pre-processor directives? define FREE (or whatever you want to call your flag) in your compiler settings on Visual Studio and some features would not be built into the code. See http://www.dotnetperls.com/if-elif-endif http://msdn.microsoft.com/en-us/library/ed8yd1ha.aspx


3

I would model something off of Vincent Driessen's Git branching model. http://nvie.com/posts/a-successful-git-branching-model/ There are plugins for git and mercurial. Bitbucket's program source tree even has the mercurial version build in. The main idea is that you have separate "swim lanes" for different parts of the development phase. You have one for ...


2

Here is an attempt at how I would try that. That may sound stupid for a developer, but to management, technological changes are seen as risky. "If the magic thingy already works, why take the risk to break it?" Thus, you have to turn the table. Make it more risky not to make the switch to git. At all costs, don't make it sound like it's a new toy. I ...


2

Yes, that is a best practice for how SVN is designed. You have your branch, you merge the trunk into your branch, because there are always issues to deal with (it is easier if you periodically do this while working on your branch), and when it's good you merge it back into the trunk. At this point there shouldn't be any conflicts unless someone else has ...


2

The policy of deliberately refusing to branch is usually a mistake, but I don't think branching is feasible in your case. Not because you are using SVN - which is the usual reason for not using branches, since SVN's handle on branches is especially crappy, even compared to SVN's general crappiness - but because of this: our product can't be compiled and ...


2

Have you tried using Git? It's free to use, requires no server, and is extremely lightweight. You can use it individually on your computer, or you can network all of your developers computers for sharing commits back and forth. Seriously, you should use version control


2

The thing to realize is the smallest commits are most beneficial to you, during development. If you wait until you're ready to push to separate out commits, you're missing out on a lot of help your tool could be providing. What you do is work on recognizing when you're switching gears, and just make a commit or a branch on the spot. That lets your tool ...


1

To answer the first part of your question about tags/commits: generally the recommended way to link issues to the code that fixes/implements them in JIRA/Bitbucket is done by creating a branch,not tags. If you name the branch with the project code and number of the issue (i.e. PRJ-123) JIRA/Bitbucket will be able to link the two issues together. To answer ...


1

What we used in a company I used to work at is Liquibase. It is a solution in Java, but since you only ever need to run it once per DB update it will likely work for other languages as well. I'm pretty sure there are other solutions that work in a similar way, so I'm just going to describe how it functions in general so you can search for something that ...


1

Legacy software isn't designed, it evolves. Svn was designed to improve CVS, which was designed to improve RCS. What did RCS replace? Think about how you would maintain branches without any version control system at all. You put them into separate directories. Putting those separate directories under version control requires a smaller leap in your ...


1

It's a snowball effect. SVN has been around a long, long time, and duplicating a directory was the easy-to-code solution. It was good enough because branching was rare. But then DVCS were invented partly to overcome perceived weaknesses in SVN, and they had great, efficient branching support. That lead to people using much more branching than ever, which ...


1

It is certainly a mistake, but not necessarily only a newbie mistake. At my last job (a highly competitive motorsports job) my boss was adamant about avoiding branching. He had about 20 years experience and still thought it was a bad idea. I completely disagreed with him and challenged his misconceptions. There are times where branching isn't worth the ...


1

From my experience, merging in SVN was 'fixed' in version 1.6. I work in both Mercurial and SVN, and since version 1.6 of SVN, merging seems to be about the same amount of work on both platforms. The one exception might be that you have to remember to provide the --reintegrate option when merging from a branch back into the trunk using SVN. This is only my ...


1

Before asking about merging, you should ask whether you need branch-based development. The answer depends solely on your project and team. I personally believe in branches for application-level "feature" development, but am comfortable with changing trunk/master for utility projects and new development (bugfixes to released projects require branches, but ...


1

That's true - if you have multiple 'trunks', each one representing a release, then you don't need a single trunk. In fact, trunk is an arbitrary name for a 'master' branch anyway (eg in the Microsoft docs for TFS they recommend using a thing called 'Main'). But there is a good reason for developing elsewhere and using the release branches just for ...


1

What I really need is something powerful enough to break through the "This process has worked for 20 years, why should we change it?" argument. It's hard to really judge what would be a good argument without being a witness of the scene. But I'll try to help you frame your arguments so that they may be heard. I assume your audience to have be a ...


1

What I really need is something powerful enough to break through the "This process has worked for 20 years, why should we change it?" argument. This is an invalid argument (horse-drawn carriages have "worked for centuries", but you probably want to buy a car instead). I have heard the same argument about svn vs. mercurial (I was the one using mercurial ...


1

You can work this way quite happily - I do nowadays and is the way to work with feature branches. There are 2 pitfall you need to be aware of though. Any work you have uncommitted with remain in your working copy, and when you switch it will be merged. this can mean you may commit work intended for the other branch. Ultimately its a person problem - you ...



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