Tag Info

Hot answers tagged

83

Oh wow, yes. I use both SVN and Git and I cannot tell you how many times they've saved my ass. More Git than SVN, but let's not start flamewars here. This is on projects I work on by myself, as well as projects I work on with other people. No excuse not to, really. As a human, I'm basically entitled to do stupid shit all the time. By using version control, ...


71

V2.0 should have had what we used call a 'steady-state branch' (we used Perforce, not TFS) made for it once it was released. Any fixes for v2 would have been made to this branch and then propagated back into the v3 development branch while v3 features were also being worked on, i.e. a defect on v2 would result in a defect also on v3. Having changes reside ...


49

Well there are multiple ways to deal with issues like that, generally covered by 'branching' tag, each with own set of benefits and downsides. But approach chosen by your developers... gee I'll quote it verbally to make sure that I didn't misread... code... will be kept on the developer's local machines until they are done... ...the way like above is ...


38

Your dev's have a fundamental misunderstanding of how to use version control. Do not get into a discussion about the "right" version control software. This is not the problem. Every code tweak is making the problem harder to fix. WHEN y'all decide to do the right thing, you cannot continue code changes while you fix things. You MUST stop all development and ...


19

As a general rule, source control is best used for source only, and generated files are not source. There are exceptions. Sometimes (using Visual Studio) you might want to keep the .pdb file for reading minidumps. Sometimes you can't duplicate a toolchain, so that you can't necessarily recreate generated files accurately. In these cases, you're primarily ...


18

Mercurial I like Mercurial provided you install TortoiseHG and VisualHG tools. The best feature is that you can create a "branch" to try out some funky new code by just copying your enlistment directory in Explorer. This copy will sync back to Codeplex without changing any settings if all goes well. If it goes poorly, delete the directory and 'all is ...


16

Name the working directories differently. That is, if your project is titled "MY_PROJECT," create a different working directory for each branch. If there is one branch named "dev," then you'd need a directory for trunk and a directory for dev, like this: ~/henginy/projects/MY_PROJECT-trunk ~/henginy/projects/MY_PROJECT-dev


15

The advantages git has come from tossing out a lot of old assumptions about what a VCS should do. The disadvantages git has come from not being able to leverage prior experience and not being able to do things the way you are used to. If you are going to switch from something else to git, try to start tabula-rasa (though it is impossible to truly do in ...


12

What you are describing is a terrible way to use version control. There should have been a branch made for release 2.0, or a tag or some identifier. That way, modifications to that release can be contained and more development can continue to happen. This article can give you some ideas. It's written with git in mind, but there's no reason that it couldn't ...


11

Both will do what you need. At my last job we started with SVN and moved to TFS later. Our team consisted of 8 developers and 3 QAs. TFS was nice b/c it had built in VS support, built in ticket tracking, and you could lock files. We also used the SharePoint to keep track of all the documents and meeting notes for each project. It was a very nice and ...


11

When I started at my first job I worked on similar projects (but with smaller scale) and we faced the same problems. We also started with general solution handling requirements for all clients but that was possible only to same point where requirements become contradictory. We did what you suggest and started separate version for each client. Even this ...


11

Martin Fowler and Pramod Sadalage have written an excellent article on this subject. Every developer has his own database to which changes can be made. These changes are then communicated back (as a changeset) to the DBA who implements them in the master database, so he's still involved in the process, he probably knows best about the structures and needs ...


11

Option A. Just using mainline and tagging for release Pros: You avoid merge hell. Keeping to the mainline encourages some best practices like proper release planning, not introducing a lot of WIP, using branching by abstraction to deal with out-of-band long term work, and using the open closed system and configurable features for dealing with ...


10

One workspace does not allow the same TFS folder to be mapped to more than one local directory. However you can have two or more workspaces for one computer, and each workspace can map a TFS folder to a different local folder. What revisions of files are in each workspace is tracked separately (to keep each up to date you need to do a get in each: easy with ...


10

You should create a new repo for each independent project. Why? Someone working on project D does not have to download all the history for E and F. Git repos are cheap to initialize, so you can use as many as you like. It is painful to work with multiple projects at once when they are represented as branches in a repo: When switching from A to B to quickly ...


9

don't go with Git just because its "pretty cool", use it because it solves your problem in a way that fits with your workflow. As for TFS... Martin Fowler had a little survey. Anyway, you have to define "security" - do you want to protect the source from unauthorised users, or to put a read-only flag on some areas, or even prevent some people from looking ...


9

This sounds like a internal process issue more than a check-in issue. You should work with the person to ensure that they are doing proper testing and debugging to ensure that the code works. If you have a group of testers, make sure he is sending them his changes to test, they are usually good at finding problems. You could also be bringing these ...


9

Martin Fowler's little survey says a lot about the state of TFS in previous years. 'dangerous' is quite right. (I think this refers to the way that it doesn't recognise changes made outside of VS, so you can create a WCF project, then use the external svcutil tool to create your client, then check all your changes in.. but TFS will happily ignore your client ...


8

Actually, I would suggest that you do not need a branching model, but rather a complete comprehensive approach to deal with the multi-dimensional constraints with regard to the system without branching. In practice, I believe it will always be a problem to maintain multiple systems that have some commonalities but will evolve differently in branches, so it ...


8

I don't work in a generic dev or trunk branch. I ALWAYS do work in feature branches. When a feature is done, I follow these steps. Open Source Control Explorer. Merge from dev into current feature branch. Fix any conflicts and ensure everything still works. Check in again. Merge feature into dev branch. Open dev solution. Checkin dev branch. Close ...


8

I've never seen a CI system doing any merging. In theory you could set it up to do that but as you mentioned the build will break if you run into any merge issues. CI environments usually have a specific fixed branch as the "build" branch and the CI server will monitor that branch for new check-ins to fire off a new build cycle.


8

I've moved from a company with a largely Atlassian stack (and Mercurial) to a company with a heavy TFS stack. I find two irritations. The first is Source Control. When you've got used to DVCS, switching back to a CVCS is painful. TFS is particularly painful because, for all that integration to work, it insists on being connected to the server at all times. ...


7

Simple answer? No. Don't do it! I can't think of many reasons not to, but no reason why you would want to. The only time I can think you would check in a dll is if it's from a third party library that you don't expect every developer to have installed to build. But even still, that's not located in the bin folder. That being said I did work at one company ...


7

Have you considered mercurial? Like git, it is a DCVS and lets you do all the neat things one can do with a DCVS. Like git there is a pretty good, cloud-based service provider (bitbucket). But, unlike git, the windows story is pretty decent, you are not a 2nd class citizen. You've got good tooling options (TortiseHG) and pretty decent Visual Studio ...


7

My general take on the best practices is that any member of the development team should be able to perform any action on the tree presuming those actions don't do things like kick off a production deployment. In cases where a specific branch / tag / repository does act as a source for automated deployments putting in some reasonable change control or ...


7

I don't trust my local hard drive not to crash overnight. Shelving = backup, for me personally. I've also been on teams that use the shelving feature for exploratory/proof of concept coding that might span several days. It let's you see how something might fit into the software without really committing to it too much.


7

Quick Answer: Development team should have a separate Production branch to keep deployed code-base V2.0 separate from the Main trunk. All the bug fixes need to be done in that branch first and then tested and deployed to other branches, in order to keep code in sync. Your project should also have have several environments for health development like Prod, ...


7

He told me it's much more secure to use an SQL Sever based tool Define (or get your boss to) "secure": security from data loss or access control? The latter certainly is easier in TFS (and I suspect that's what he/she wants). So the question is who would you block from access? Using multiple Git repositories with limited users performing pulls from ...


6

Should both those stories share similar tasks since the development and design are similar? Yes. Should I break up the features into separate stories? No. Stories aren't features. They're stories. You invent features that will support the stories. It's called "design". You don't -- unthinkingly -- just code from a story. First, you think. ...


6

I'm not fond of arbitrary branches i.e. Fred's bugfixes or Harry's bugfixes. I'm much more comfortable with one (independent) feature one branch which allows multiple developers to operate on one feature; but for the feature to be merged only when it's complete. So, right now you only need the "bugfix" branch but once you start development you should crate ...



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