Tag Info

New answers tagged

6

No, not a good idea. Source Control is named that way because it contains source, not the compiled result, or test output in your example. Test logs are temporary files that are used only to debug tests, and thus should not be present in the source control.


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 ...


0

I guess we have some sub cases here if you consider unit/integration tests feature branches and CI It seems fairly obvious to me that when you commit, or merge to a shared branch. You should commit code with passing unit tests and integration tests you believe will pass. If you split the commit/merge then you have a branch with a state which either... ...


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 ...


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


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. ...


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

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 ...


0

It might be that git-subtree (see Atlassian blog, medium blog, or kernel link) would be a good fit for that you have. So, each of your top level project would use a set of subtree at possibly different version(s).


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 ...


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 ...


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 ...


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. ...


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 ...


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 ...


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 ...


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 ...


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 ...


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

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 ...


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 ...


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 ...



Top 50 recent answers are included