

Switched from Subversion to Git - stuff4ben
http://concise-software.blogspot.com/2009/08/git-scales-enough-for-enterprise-java.html

======
wvenable
I wish git was bit more user-friendly on Windows. With TortioseSVN, using
subversion is so smooth and easy I almost forget it's there. I've got a bunch
of Git tools installed in Windows, but it's all so horrible. The GUI tools are
significantly worse than using Git bash at the command line.

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.

~~~
ghshephard
Have you tried TortoiseGit? <http://code.google.com/p/tortoisegit/>

~~~
davidw
How is that shaping up? Ready for production use? For people who don't know
too much about version control?

------
gruseom
An amusing combination of titles:

 _In Search of Concise Software_

 _Git Breezily Handles our 500,000-line Enterprise Java Project_

~~~
henning
I wonder what that 500,000 lines buys them.

~~~
jrockway
200,000 getters and setters.

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

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

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

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

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

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

~~~
tezza
_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.

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

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

------
smithjchris
Most "industry" developers can barely use Subversion. How are they supposed to
handle Git?

~~~
nudded
by reading this book : <http://progit.org/book/>

~~~
jrschulz
If only those developers read books...

~~~
smithjchris
Precisely my problem... apathetic developers!

