Hot answers tagged

175

You can loosely replicate the role source control plays with three simple tools: Back-up software (Commits/Check-ins) Folders (Branches) Performing a directory merge between two directories using a tool like KDiff3 (Merging branches) Basically your workflow becomes: Create a new folder (new branch) Copy files to the new folder (new branch) from an ...


154

It's not overkill. The main reason why I started using Git and Mercurial over Subversion for personal projects is that initiating a repository is so much more easier. Wanna start a new project? > git init BAM! No need to set up a repository server nor check in a folder structure to support branching and tags into a subversion repository. Sharing your ...


150

Use tags to mark commits with version numbers: git tag -a v2.5 -m 'Version 2.5' Push tags upstream—this is not done by default: git push --tags Then use the describe command: git describe --tags --long This gives you a string of the format: v2.5-0-gdeadbee ^ ^ ^^ | | || | | |'-- SHA of HEAD (first seven chars) | | '-- "g" is for git | '-...


139

Although the consensus would certainly be to not work for this company I don't believe that really answers your question. You can't really replace SCM. You might not need the usual bells and whistles of a full-blown system. For example, the company may refuse a request for a server, but permit the use of a local SCM. They may dislike git, but permit ...


110

The problem with adding a comment to a file that it should be deleted, instead of deleting it in source control and putting the explanation there, is the assumption that if developers do not read commit messages that they will surely read comments in source code. From an outsider's perspective, this methodology seems to be rooted in a very conservative view ...


105

Yes it is bad practice. You should put the explanation for the deletion in the commit message when you commit the deletion of the files. Comments in source files should explain the code as it currently looks. Commit messages should explain why the changes in the commit were made, so the commit history on the file explains its history. Writing comments ...


90

Is there a point at which the process gets in the way and becomes an end unto itself? Heavy processes are common, unfortunately. Some people - especially management - religiously imagine that processes produce products. So they overdo the processes and forget that it's really a handful of hard-working, smart people who actually create the products. For ...


69

It means that when you do a commit to the version control system either everything you want to commit goes in, OR nothing does. In CVS, when you try to commit it's possible for the commit to succeed on several files, then fail on several others (because they've changed). This leaves the repository in an unfortunate state because half of your commit isn't ...


68

The premise you are questioning really is wrong: that one major advantage of Git over Subversion is that Git gives all the source code to the developer locally With both Subversion and Git you have your source code locally. With Git you have both your source code and a repository on your local machine. It goes something like this. Subversion: Your ...


59

Some suggestions: There is nothing wrong in having a lot of feature or bugfix branches as long as the changes done in each branch are small enough you can still handle the resulting merge conflicts in an effective manner. That should be your criterion if your way of working is ok, not some MSDN article. Whenever a branch is merged into trunk, the trunk ...


57

There are several problems when commits are directly pushed to master If you push a work-in-progress state to remote, the master is potentially broken If another developer starts work for a new feature from master, she starts with a potentially broken state. This slows down development Different features/bugfixes are not isolated, so that the complexity of ...


52

Sites such as Ohloh and Github only give you an indication of what's going on in the open source world, and take no account of the (much larger) commercial/industrial/closed source side of things; Google Trends gives all sorts of other hits for "subversion" and "git" (both of which have other meanings outside the SCM world). The best indicator you're likely ...


46

I would contend that using Subversion for local personal projects is overkill, whereas Git is decidedly not. Git will take up less space (because of SVN's inefficient "revisions" concept versus Git's object snapshots), requires less setup (git init versus a dozen svnadmin commands and setting up permissions and so on), is easier to back up (git clone --bare [...


46

SVN is not dead at all. It's is still in extremely wide use, and it's not going anywhere anytime soon. SVN is much simpler to use than distributed version control, especially if you're not actually running a distributed project that needs distributed version control. If you only have one central repository (which is all your company will need if they're ...


46

You're looking for a technical solution to a human problem. That rarely works. The reason for that is because if team members do not accept something (nor understand the implications), instead of following the rules, they'll attempt to circumvent them. That's exactly why, for example, developers should accept and understand style rules instead of just being ...


44

You are confused about the role of a version control system. It is not and never was intended to be a backup system for a running web site. It does an extremely good job of managing static content so that it moved into production in a controlled manner. With proper use of tagging and automated checkouts, even fast changing sites can be kept in a version ...


44

if you know what you're doing, you shouldn't (and shouldn't ever have to) re-merge a branch in the first place. (Of course it's difficult to do when you're doing something fundamentally wrong and silly!) And therein lies the source of your confusion and the whole problem in general. You say that merging branches is "fundamentally wrong and silly". Well, ...


40

This has come up on a few projects for me. The best solution I've had so far is to generate a version number like this: x.y.<number of commits>.r<git-hash> Typically, it's generated by our build system using a combination of some static file or tag to get the major revision numbers, git rev-list HEAD | wc -l (which was faster than using git ...


35

Yes. You never know when more people might be brought on to the project. Also, repos allow you to rollback when you accidentally add something that doesn't work. You could use git for version control on your own machine without the need for a centralized repo. However, as long as you're using git, you might as well set up a repo on on GitHub. It only ...


34

To think you will never branch your own code is a little short-sighted. I've branched my own code several times, particularly when I was experimenting with a new approach I wasn't entirely convinced about yet. You'll eventually want the feature. This is coming from a long time Subversion user. Consolidating on one tool can really help make your life ...


32

Wrong is too strong a word, because this is a matter of style/preference. However, my preference is apparently diametrically opposed to yours. I much prefer seeing coding style edits and small documentation changes done in their own commits. If I'm doing a code review, or trying to figure out where a bug was introduced, it's much easier if each commit ...


31

The easiest way to set up a local server is to use svnserve: Subversion includes Svnserve - a lightweight stand-alone server which uses a custom protocol over an ordinary TCP/IP connection. It is ideal for smaller installations, or where a full blown Apache server cannot be used. You don't actually need a subversion server though, if all you want to do ...


28

To add to Jan's answer, Ohloh has been crawled (only) three times by the Internet Archive's Wayback Machine, but July 2011 is unreadable, so that gives three data sets including today (plus future edits): August 2010 Git: 26,485 repositories (11.3% of total) SVN: 25,336 repositories (10.8% of total) SvnSync: 117,326 repositories (50.0% of total) Note: ...


26

Disclaimer: I work for Atlassian DVCS does not discourage Continuous Integration as long as the developer pushes remotely on a regular basis to their own branch and the CI server is setup so that it builds the known active branches. Traditionally there are two problems with DVCS and CI: Uncertainty of integration state - unless the developer has been ...


25

Do you read it or not? Yes. If you do, how often Daily. Constantly. I work with numerous open-source projects (mostly Python-related) and must read the source because it's the most accurate documentation. and what's the procedure of reading the code? Um. Open and Read. Also, it's a bit difficult for newbies to deal with SVN - a bunches of ...


25

Basically, there is a management problem (your organization don't understand the basics of software development process, e.g. the V-model) condensing into the apparent inability of using minimal present-era workflow, methodology, and tools. This is common (read about Peter's principle). BTW, I guess that recent SNCF railway incident in Paris at end of 2017 ...


24

Personally, I update my local versions daily. In the scenario you describe, I would go the extra mile by Creating a branch for the new, lengthy feature. Merge often from the mainline to this new branch. This way, You can check-in daily to preserve your code on the server You don't have to worry about breaking the build by checking-in. You can use the ...


22

SVN works on both case sensitive and case insensitive filesystems, so it must assume the most compatible option, which is case sensitivity.


22

Companies typically suffer from what I'd like to call the Control-Flexibility dilemma. The less rules, structures and bureaucratic overhead the easier and faster it is to accomplish things (it's also more fun). However, it is equally easy to do "bad" things as "good" things. That means you're only fine when you have skilled employees which make few non-...


22

When it comes to git, I believe one should commit as often as possible - some people commit every successful compilation. Don't confuse commits with pushes - a local commit does not have to be pushed (and with git, you should use many branches as they are cheap). This should be the rule all around, but some SCMs are too slow for such a rule. Personally, ...


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