Switched from Subversion to Git(concise-software.blogspot.com)
concise-software.blogspot.com
Switched from Subversion to Git
http://concise-software.blogspot.com/2009/08/git-scales-enough-for-enterprise-java.html
4 comments
Have you tried TortoiseGit?
http://code.google.com/p/tortoisegit/
How is that shaping up? Ready for production use? For people who don't know too much about version control?
I don't consider SVN user-friendly. It might use pretty fonts in the UI, but one wrong move, and your data is lost forever. ("svn update" is especially bad about this.)
With git, any operation I perform can be reverted via the reflog. Even reverts can be reverted! That beats any shiny UI any day.
With git, any operation I perform can be reverted via the reflog. Even reverts can be reverted! That beats any shiny UI any day.
Any more details on svn update being especially bad at killing your data forever? We've been using svn for 5.5 years now and I've never personally lost data with any of the available clients. (I can admit that svn revert does irretrievably destroy client-side changes, but that's what the command is designed to do, so...)
Consider the (common) case where you modify some files, want to commit them, get the "your tree is out of date, run svn update", run svn update, and then have the svn update merge fail; some files updated, others conflicted.
Once you run svn update, your working tree is gone forever. And often, you can't save your changes until you risk blowing them away. That is Very Bad.
In git, you can't destructively update your working tree (via a merge, anyway) until you have committed it. Once you commit, you can "git pull --rebase", fix the conflicts, and push the resulting tree. This is svn's workflow, except that if you don't like what happens you can just say "git reset --hard HEAD@{0}" and try again later.
Once you run svn update, your working tree is gone forever. And often, you can't save your changes until you risk blowing them away. That is Very Bad.
In git, you can't destructively update your working tree (via a merge, anyway) until you have committed it. Once you commit, you can "git pull --rebase", fix the conflicts, and push the resulting tree. This is svn's workflow, except that if you don't like what happens you can just say "git reset --hard HEAD@{0}" and try again later.
Interesting, I've used svn for about four years and have never "lost" anything I've changed in my working copy. I've certainly had some cases of merge conflicts that were tedious to resolve, but my changes were all "there". And if you're working in a branch and commit to your branch before you try to merge back into trunk, you can always get everything back if something goes awry.
I'm not saying git doesn't handle this better; I have not tried it yet myself. But in my experience it's possible to use svn without risk of losing your changes.
I'm not saying git doesn't handle this better; I have not tried it yet myself. But in my experience it's possible to use svn without risk of losing your changes.
When you run svn update and get a conflict on file foo.c, the contents of foo.c indeed have the conflict markers, but svn helpfully leaves you a file called foo.c.mine, which is your originally modified file.
I'd hardly call that "gone forever".
I'd hardly call that "gone forever".
No, I'm saying your tree is gone forever. The files that did not have conflicts have already been merged, but the files that do have conflicts are in their old state. You can't always go back to the "before svn update" state.
(This is why I use mercurial.)
There's an eclipse plugin, if you use eclipse. But yea the user-friendliness of Git needs work. If you setup some web manag frontend for git it might make some parts of it easier. Using trac+git or redmine+git would allow you to at least visualize the repository.
An amusing combination of titles:
In Search of Concise Software
Git Breezily Handles our 500,000-line Enterprise Java Project
In Search of Concise Software
Git Breezily Handles our 500,000-line Enterprise Java Project
500,000 lines may be extremely concise for what it does :/
I wonder what that 500,000 lines buys them.
I am also not sure why it matters - we switched 3,000,000+ lines of code from subversion to git, but the effort was not really correlated with LOC. The major overhead of switching from subversion to git is the learning hit on the developers (though it is certainly worth it for many of the reasons described in the OP).
200,000 getters and setters.
I'm not convinced language snobbery is something to be encouraged personally :/ If it was lisp it'd be 200,000 lines of parenthesis, if it were python it'd be 200,000 of significant whitespace, perl? 200,000 of random punctuation characters etc etc.
It's not the language, it's what you do with it that counts. If someone is writing countless getters and setters, in any language, they're clearly doing something terribly wrong.
my 2c.
It's not the language, it's what you do with it that counts. If someone is writing countless getters and setters, in any language, they're clearly doing something terribly wrong.
my 2c.
Sure, but at the same time all languages were not created equal. Some are better designed and more powerful than others. They're not all just equally great at different things and let's sing "Kum ba yah" together now.
> 200,000 of significant whitespace
Significant whitespace does not occupy its own lines in Python.
Significant whitespace does not occupy its own lines in Python.
But has anyone fixed this in Java yet, or does every large app still consist of thousands of nearly-identical methods?
Things like parentheses and whitespace don't affect the ongoing maintenance of your codebase; a bunch of code that your IDE typed for you does.
Things like parentheses and whitespace don't affect the ongoing maintenance of your codebase; a bunch of code that your IDE typed for you does.
Using your IDE to type code for you is the problem. Not Java. Place the blame where it should be. If a programmer is foolish enough to use an IDE to generate code, and doesn't mind if it's near identical rubbish, then it's not the languages fault anymore.
So could you explain the "right way". I'm not a Java programmer, and googling did not reveal any way to generate accessors other than inserting code in your source file.
An explanation of how you do it would be very valuable, at least to me.
An explanation of how you do it would be very valuable, at least to me.
I think it's called inheritance, but most programmers try to stay away from that because of the headaches of the diamond problem.
If it was lisp it'd be 200,000 lines of parenthesis, if it were python it'd be 200,000 of significant whitespace, perl? 200,000 of random punctuation
How do you know this?
How do you know this?
[deleted]
In a comparably sized codebase at my job, there's connectors to this and that idiosyncratic/complex external system (some of which require for example extinct dialects of SOAP), there's legacy cruft, there's systems that draw together multiple providers and present a unified interface, or that distribute commands to the proper subsystem, and there's a ton of reports and front ends and back ends for multiple years of customers, which get remixed and reused.
500,000 lines isn't a lot of code. The compiler I work on has almost that many lines, but the larger product (IDE) has many millions.
"500,000 lines isn't a lot of code."
in Java. Not to spawn any language wars, but imagine 500,000 "lines" in something like J, FORTH or even Factor.
in Java. Not to spawn any language wars, but imagine 500,000 "lines" in something like J, FORTH or even Factor.
Does anyone have a real world example of a busy dev shop with a bunch of stretched coders that are accustomed to tortoise svn only based source control switching to git? the coders at this place range from brilliant to pretty good, but I don't think some of them would be capable of wrapping their heads around msysgit and they're thoroughly wedded to windows.
Tortoisegit viable? Looked ok from my brief experimentations, but I know that's different to actually doing real work with it...
Tortoisegit viable? Looked ok from my brief experimentations, but I know that's different to actually doing real work with it...
Why do you want to switch to git? I say this as someone who uses perforce, subversion, git and mercurial on a regular basis. Version control is largely similar for the 90% of your work life, and that 10% can usually be solved by hand.
Why do you want to switch to git? Agreed, I don't know either.
Any sort of branch/merge problems I encounter are mostly coders working on mutually incompatible versions of the base system. Not on a file level but rather on a protocol/format level
No mere source control system will be a hurdle of the same size as the hurdle of co-ordinating all the developers who broke each others preconditions.
---
So a switch to git will be best for projects with extremely stable interfaces where the branch/merge mechanism is the most time consuming part. Think: linux kernel, stable protocol services.
But where developers have to collaborate while modifying a shared framework git makes little difference. Think: early stage GUI frontends, or server components which inter-depend on message formats which are evolving.
Any sort of branch/merge problems I encounter are mostly coders working on mutually incompatible versions of the base system. Not on a file level but rather on a protocol/format level
No mere source control system will be a hurdle of the same size as the hurdle of co-ordinating all the developers who broke each others preconditions.
---
So a switch to git will be best for projects with extremely stable interfaces where the branch/merge mechanism is the most time consuming part. Think: linux kernel, stable protocol services.
But where developers have to collaborate while modifying a shared framework git makes little difference. Think: early stage GUI frontends, or server components which inter-depend on message formats which are evolving.
Git not being centralized helps a lot in the initial-development scenario. Two developers can pull changes from each other without polluting a centralized repository.
It looks like git / bzr / hg have better mechanisms than svn in the case you mention.
Those same mechanisms break just as badly as svn when you need to coordinate 10+ developers. The communication overhead of the developers dwarfs the way they sync files.
Those same mechanisms break just as badly as svn when you need to coordinate 10+ developers. The communication overhead of the developers dwarfs the way they sync files.
quite a few reasons, none of which aren't covered in tha parent post except for one, which is that subversion on test environments is a real pain to get working on various environments. As the dev team uses tortoise and always gets "there is a new version available, please update here" I have seen the unenviable position of having repos on staging environments rendered un-updatable except by tarball because subversion on the remote end refusees to work with the newly incompatible repository post a single commit from tortoise SVN 1.6.3 for example.
This is not a problem with git, and the being able to push updates directly to the staging environment can also be non -trivially handy too.
That said, that's a minor annoyance vs the full blown excellent points that the original article makes about the advantages of git over subversion, so I'm a bit puzzled as to why this question is being asked, did you not think that the things covered in the article were worth anything?
This is not a problem with git, and the being able to push updates directly to the staging environment can also be non -trivially handy too.
That said, that's a minor annoyance vs the full blown excellent points that the original article makes about the advantages of git over subversion, so I'm a bit puzzled as to why this question is being asked, did you not think that the things covered in the article were worth anything?
I'm just saying in your case it seems as if people are busy enough as is. Switching VCS will disrupt workflow as they learn. My experience is that branches, while a pain in non-git systems are still used in the places you really want them to be used (release management), and most of the other features are mostly in the "nice to have" category. At that point it seems a better idea to simply use git-svn so you have the power of git without having to force a change in infrastructure.
(Incidentally, you can turn off subversion's auto-updating. I try to keep all my computers running the exact same version of subversion for largely the same reasons you mention.)
(Incidentally, you can turn off subversion's auto-updating. I try to keep all my computers running the exact same version of subversion for largely the same reasons you mention.)
What I'm actually thinking of doing is using git for my own projects internally and as other devs help me out on those projects I'll induct them properly into how things work on that project, one small aspect of which will be git, and it won't be the only one, so they'll already be in a learning frame of reference from there. That said, keeping it as close as possible to the way it was is a good goal from a "I get this, it's easy to work with" perspective so I'd still really like to know if tortoisegit is as practical for real work as it appears to be from messing with it briefly in a VM.
Someone care to save me from a couple of days in windows again? :)
Wrt git svn, last time I tried that it started version controlling the .svn directorise o_O. Which was fine for git svn but the tortoise svn users were completely screwed on a checkout.
Wrt subversion versioning woes, yeah, it's kinda a solution, but at the same time I'm not the system administrator and really don't want to be, and trying to enforce "don't update" would suck even if I were.
Someone care to save me from a couple of days in windows again? :)
Wrt git svn, last time I tried that it started version controlling the .svn directorise o_O. Which was fine for git svn but the tortoise svn users were completely screwed on a checkout.
Wrt subversion versioning woes, yeah, it's kinda a solution, but at the same time I'm not the system administrator and really don't want to be, and trying to enforce "don't update" would suck even if I were.
Most "industry" developers can barely use Subversion. How are they supposed to handle Git?
by reading this book : http://progit.org/book/
If only those developers read books...
Precisely my problem... apathetic developers!
That seems to presume Svn is easier to use than Git, in my opinion it is the other way around.
I think, for Git, the GUI I'm looking for probably isn't possible. It's designed with the philosophy of small command line tools combined together -- that's not something you can paint over with pretty UI.