You can loosely replicate the role source control plays with three simple tools:
Back-up software (Commits/Check-ins)
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 ...
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:
^ ^ ^^
| | ||
| | |'-- SHA of HEAD (first seven chars)
| | '-- "g" is for git
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 ...
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 ...
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 ...
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 ...
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 ...
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.
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 ...
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 ...
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 ...
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 ...
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 ...
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, ...
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 ...
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 ...
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 ...
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 ...
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):
Git: 26,485 repositories (11.3% of total)
SVN: 25,336 repositories (10.8% of total)
SvnSync: 117,326 repositories (50.0% of total)
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 ...
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 ...
It's because svn lacked the proper data structures to accurately determine the latest common ancestor of the two branches. That's not a big deal for a branch that is only merged once, but can cause a lot of erroneous merge conflicts in situations where several branches are merged multiple times.
I don't follow svn very closely, but my understanding is ...
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 ...
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.
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 ...
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.
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-...
A different tool is probably not going to solve your problem, I'd say you should read this article, I found it most helpful:
I think the main point of the article is summed up here, but please do read it:
In The End: Not Really About The Tools
In all of the time I’ve spent working with ...
Please see my Stack Overflow answer for a very concrete situation where Mercurial (and Git) merges without problems and where Subversion presents you with a bogus conflict. The situation is a simple refactoring done on a branch where you rename some files.
With regard to tdammers answer, then there is a number of misunderstandings there:
There is nothing too difficult about SVN merging... anymore... if you follow the right philosophy
What I see in most other answers seems to come from people who haven't used SVN in a while. As someone accurately mentions: "it wasn't fixed early enough to dispel the myth".
From my current experience of using SVN 1.6 to 1.8 on a legacy project I inherited ...
I think the answer is given in the subsequent sentence:
Keeping stable and dev code separate is precisely what source code control is supposed to let you do.
By using #ifdef blocks, you are emulating functionality of a source control system with a C preprocessor. It's the wrong tool for the job.
The downside is that you probably either end up ...