Tag Info

Hot answers tagged

28

You've written down a few pointers for them, but you haven't explained why is your approach better than the one they already use. This may be problematic. If you're in a spirit “We'll do it my way, because I have six years of professional experience, and you don't” (and reading your question, it looks exactly this way), be ready to be hated by your team ...


19

You should commit often. But @durron597! I'm a beginner programmer! I don't trust my commits! This is why you are committing on a separate branch! You can even have many branches that you're committing to for your own use, for different fits and starts and experiments and whatnot. Don't worry about big fancy commit messages. The only commit messages that ...


16

For a team of 3-4 devs, you're proposing WAY too many branches. Every branch you create is additional overhead that comes with a cost (time spent merging, keeping track of what's where, etc). You need to make sure that the benefit you get from having a branch outweighs the cost. Keep in mind that the only real benefit to a branch is code isolation. ...


10

SourceForge is not considered trustworthy anymore. It has been hijacking accounts and replacing Windows packages with adware installers (GIMP, nmap, and others). SourceForge has also been active in filtering out users from specific countries. Nothing really prevents other hosting services from interfering with software installers since we have yet to see SF ...


8

Version control is not the issue here. It's a fundamental principle of programming that says "Don't repeat yourself". It's a time-honored maxim, largely for exactly the reason you cite. If at all possible, arrange things so that the logic you write lives in one place and one place only. I know nothing about Matlab, so I have no diea whether it's possible to ...


4

This is very similar to a successful git branching model that we've employed in my workplace - it works wonders for us (though we differ slightly from your branching a little, and put the git tag on production server so that devs don't patch live and update git via production server (and possibly fubar the branches)). When developing Your proposed method ...


3

Like Mainma says, be careful with the branching. You mention branching every few weeks, is it really necessary to have a lot of branches? Alternatively, you could also have a 'pull' model instead of a push model. If you were using Git or Mercurial, you could have an integration server validate their changes before pushing to the central server. In TFS, you ...


3

It is good practice to building your code only once and not per environment or branch. Your GIT branches should not be directly connected to your environment stages. The pipeline should be as follows: develop > merge to baseline > build > upload to repo > deploy on dev > test > deploy to Staging > test > approve > deploy to 1 Prod > test > to n Prod. ...


3

Pick your choice - do you prefer always getting a warning when there might be a potential conflict in the near future since two people are going to edit the same file (Clearcase)? Or do you prefer to get a warning when the VCS detects there is an actual conflict since the two people edited the same source code lines, or lines very near to each other (Git)? ...


2

Version control isn't what you need here. You need to put your code which lives in many places in a single place. A good first step would be to create a folder for your shared code, copy the shared code into functions in that shared folders, and replace the original copies with function calls to the code in the shared folder. Here is the documentation to ...


2

I'll describe how this is typically handled in github. However all of that is just code, so it is relevant elsewhere. Really spiffy projects like the ones I run, have tests to make sure everything is working okay. Furthermore, the way cool projects like the ones I work with have some sort of continuous integration. That just means there is a way for some ...


2

First of all, Git is a decentralized VCS (as opposed to ClearCase, which is very centralized: see "What are the basic clearcase concepts every developer should know?") That means, there is no central server to keep track of a "locked" file. Secondly, you generally don't just pull, but you pull --rebase with autostash in order to replay your local (not yet ...


2

In one case the person who locks first wins. In the other case the person who is ready to push first wins. Most of the time, the person you want to have precedence is the one who is ready to push. If I have a week left on my new feature, and you are done fixing a bug for today's release, you should have priority on checking in. This leads to a lot of ...


2

This is the solution I've come up with. All projects which need to be kept in different deployed server environments will have two branches: master and development. The master branch will be the branch with the latest production version. The development branch will contain all active development. Our CI will be hooked up to both the development and master ...


1

It's really no different than any other change. If it's a significant amount of work, run it by the mailing list first. Someone may already be working on it. If it's a trivial amount of work, just do it and submit a pull request with a clear explanation. The worst that will happen is it will get rejected. Deprecation is done for different reasons, and ...


1

You have changes to commit, but they are based on an old version. That's no good. In any source control system, you can rebase your changes so that they are now based on the current version. That's not automatic, it is work, there might be conflicts, but it's all unavoidable. So far, everything's the same. But because the process of rebasing and retesting ...


1

The standard git flow model should work fine for you based on what you've said. Here's how we use it: All work is done on develop (or a feature branch if we might want to do a release before a given feature is complete). When we are ready to call something a release, we create a release branch from develop and deploy this to test. Any bugs that are raised ...


1

I'm wondering if this is possible Yes. Apache+SVN is a question of hours with SVN Book, svnserve'd server (but I'll recommend Apache-way) - minutes and if so is it easy enough to achieve? Yes


1

Christopher did a very good job of enumarating the disadvantages of a one-project-per-repository model. I would like to disucss some of the reasons you might consider a multiple-repository approach. In many environments I have worked in, a multi-reposity approach has been a reasonable solution, but the decision of how many repositories to have, and where ...


1

To add to the points everyone else has been making, don't forget that there are perfectly good Distributed Version Control Systems (DCVS) that work very well. I personally prefer Mercurial as a .NET developer, but there is an equally strong case for Git as well. There is a really good answer here on the advantages of a DCVS over a traditional CVS system ...



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