
A Git user’s first (and hopefully last) foray into SVN-land - cool-RR
http://blog.garlicsim.org/post/9583964892/a-git-users-first-and-hopefully-last-foray-into
======
mberning
Well, when you revel in your own ignorance of the technology you are trying to
use then it's no surprise you run in to friction. 5 minutes on google could
have cleared up most of his gap in understanding how SVN works.

~~~
burgerbrain
Googling your questions and figuring it out does not an interesting article
make. I find this a fine counterpoint to people who come to git from other
version control systems and baulk when they see it, it's an interesting
alternative perspective to the whole "good UI/bad UI" discussion.

~~~
mattmanser
This has little to do with git vs SVN and everything to do with an inflexible
and inexperienced know-it-all being incapable of even trying to pick up an
older technology. Read through his replies to the comments, it's sad to see
really.

You could have replaced the topics of svn and git with C++ vs python or stored
procedures vs parameterized queries and it would have been practically
identical apart from people would have told him to sod off and grow up instead
of changing their process.

That's actually the only positive take away from this article, it is actually
really easy to change version control system if you want to.

I must admit I'd love to see the post he'd make after being forced to use MS
VSS :)

~~~
cool-RR
Sometimes it's better to be inflexible.

What's better, a development team full of developers who are flexible enough
to use a crappy technology, or inflexible enough to move the product to a
superior technology? It depends on moving costs and the difference between
technologies, but in some cases I think that inflexibility is better.

~~~
mibbit
A good developer can work with crappy tools and make great things.

~~~
burgerbrain
Why should they have to? Why would anyone expect them to do so? The job market
is pretty great for good developers right now.

~~~
mibbit
And there's a hell of a lot of bad developers out there.

~~~
burgerbrain
And you explicitly called out good developers.

"A _good developer_ can work with crappy tools and make great things."

So what exactly is your point here?

------
pilif
The OP could just have used git-svn. While it's not totally perfect, it allows
him to have the feature branches he likes so much and it would allow him to do
(local) rebases to clean his commits.

I did so in our project for a long time (about a year - never had issues)
until I was sufficiently sure that everybody was on the boat for git, so I
could be anal about the quality of my commits and use git to its fullest while
everybody else could continue to use svn.

Of course once we needed public branches, everybody had to move to git because
as I'm used to saying "while SVN _perfect_ for branching, it just plain can't
do merges" and from time to time, you just got to merge, so you should
probably be using a system which actually allows you to.

~~~
cool-RR
In my experience, using a system that tries to bridge between two technologies
like Git and SVN will result in having to deal with a lot more weirdnesses
than each technology individually.

In general, the amount of bullshit you'll have to deal with from a piece of
software is inversely proportional to the number of users of that software.
And the number of users of git-svn is much lower than both SVN's and Git's.

~~~
darklajid
Hmm..

But you didn't try, now, did you? You state you used SVN twice only and the
first time was very brief.

So..

\- The claim is useless (your experience in general might not be relevant
here)

\- The 'inversely proportional' line is a gut feeling, not helping - and the
whole comment here was a copy/paste from your blog comment.

Several people point out that there might've been a good solution and you
cross-post 'Yeah.. I don't believe that. And let me hide my personal belief
behind some math related statements' and even refer to that answer of yours
when _even more people_ tell you that you should've tried git-svn (again on
the blog, replying with 'see what I replied to X')?

I'm confused. Why are you so confident that you didn't miss out an easy
solution?

~~~
cool-RR
Does git-gui work with git-svn?

~~~
JustAGeek
Yes, it does, why shouldn't it?

1\. Edit some files

2\. start git gui and commit

3\. repeat 1+2 as many times as you want

4\. git svn dcommit

5\. all local commits will now be committed to the SVN repo

------
mibbit
Some people love working with branches. I don't.

It's down to how you work, who you're working with, and the processes you have
in place.

My personal motto is just "don't break the build". It seems messy to me to
create a ton of branches with broken stuff on them, having to remember the
state of everything, what's been merged, what hasn't. I'd rather just write
code to a single trunk. If I need to do big arch changes, I do them in bits
that don't break the build.

Time is linear. So is my trunk. I develop linearly. I don't think in branches.

I can totally understand that other people see things a different way, and
prefer to work like that. But I cannot. I tried. It was awful, painful and a
waste of time.

So enough with the "This is better than this" mentality :)

~~~
spacemanaki
I think there are some features where SVN is superior to Git (dealing with
large binary files?) but I think you could basically use Git in the fashion
you describe, and it would be a better experience than SVN. Just being able to
quickly checkout old versions without touching the network is awesome.

On the other hand, as soon as you bring a bunch of people working on a project
together, isn't the development inherently non-linear, and there's the
possibility that you will need to deal with (implicit) branches? I guess if
every person committed to the trunk frequently you wouldn't need to.

> So enough with the "This is better than this" mentality

I understand the sentiment, and the desire to avoid flamewars and endless
bitching about tools, but no thanks. If I never have to deal with CVS telling
me that every single file in my tree has a conflict in it again, I will be
very pleased. If no one had a "This is better than this" mentality, we might
not even have the choice of Git (or even SVN for that matter).

~~~
to3m
SVN is better than git for ANY binary files, really, because with no
centralized repository it's rather hard for git to implement any kind of
locking. Locking is pretty much essential for binary files, since most are not
mergeable in any meaningful way. It's literally NO USE AT ALL to be forced to
make somebody redo their recent work when there's a conflict :)

SVN's locking ain't so amazing, it must be said, because it's clearly not the
way it's intended to work. But it's better than nothing, certainly, and
TortoiseSVN on Windows has some nice features that make it work fairly well.

Another issue is the filling of your hard drive with crap - obviously git
keeps the entire repository locally, and SVN keeps a previous revision (I
think?), which is a bit useless for enormous hundreds-of-gigabytes
repositories mostly filled with stuff that's not significantly further
compressible. To add insult to injury, git then spits in your face by not
letting you retrieve only part of the repository! - well, obviously the
problem is that git just isn't designed for this kind of thing, not that its
decisions are unreasonable. Shame, though... some kind of binaries-and-locking
support would be nice. It would be great to be able to use git for everything.

~~~
wladimir
I'm pretty sure that git does allow working with only part of the repository.
You need to provide some specific options when cloning...

~~~
aidenn0
You're wrong.

You _can_ create a git repository that has other git repositories in it
(submodules) but you can't checkout an arbitrary subtree of a git repository.
I spent a long amount of time searching for this, so I know.

Now, people have written scripts that will convert a directory to a git
submodule by moving history around and stuff like that, but you need to check
out the whole repository first.

~~~
wladimir
Sorry, I meant "part of the repository" as "part of the timeline", not "part
of the directory structure". You don't need to fetch the entire history.

------
reemrevnivek
> _I wanna make a small change to the code to add [Feature X], I’ll just make
> a little branch, alright?_

I suppose this is a product of growing up on Git. Growing up on SVN, I'd just
add the feature.

> _I was looking for the SVN equivalent of .gitignore: A list of file patterns
> that do not get source-controlled, ever. \ It turned out that SVN’s ignoring
> mechanism is far more complicated than that...._

You're perfectly able to use a '.svnignore' file, if you like. In fact, the
"Ignoring unversioned files" chapter ([http://svnbook.red-
bean.com/nightly/en/svn.advanced.props.sp...](http://svnbook.red-
bean.com/nightly/en/svn.advanced.props.special.ignore.html)) describes how to
import .cvsignore files, which are another predecessor to .gitignore files.
(Note to OP: If you hated SVN, just stay far, far away from CVS). SVN gives
you a lot more rope with respect to properties if you want to do more complex
stuff with properties (and yes, you can probably hang yourself with this rope
- see [http://svnbook.red-
bean.com/nightly/en/svn.ref.properties.ht...](http://svnbook.red-
bean.com/nightly/en/svn.ref.properties.html) for some use cases).

The list of file patterns that don't get version controlled is known by
Subversion as the svn::ignore property. The property syntax is similar to that
of .gitignore files; simple .gitignore files are likely to be 100% compatible
(notable differences are: no comments (but if you have a file called '# These
files are generated by the compiler', we have other problems), and no `/`
character support). You set this property (like all properties in SVN) with
the `svn propset` (aka `svn ps`) command. See [http://svnbook.red-
bean.com/nightly/en/svn.ref.svn.c.propset...](http://svnbook.red-
bean.com/nightly/en/svn.ref.svn.c.propset.html) for documentation. You can use
files as arguments to this command, and you can set it recursively.

Run the following command (which doesn't seem baffling) in the root of your
working copy to set your ignore properties from a global ignore file:

    
    
        svn propset --recursive --file .svnignore .
    

Note that you'll need to run this command every time that you edit the
.svnignore file.

~~~
burgerbrain
I think the issues are:

1) "a _global_ ignore file"

2) In subversion you have to run a _44 character long command with one
subcommand, two flags, and two file arguments_. In git you have to do....
_nothing_.

~~~
parfe
So edit ~/.subversion/config and never deal with ignores again.

Acting like subversion does this in a less than optimal way is ignoring what
the command is actually doing. With subversion method you can check out a
subtree. Git can do no such thing.

I prefer git, but being able to check out say, only /project/doc/ or
/project/static/images/, is useful in subversion.

~~~
burgerbrain
I'm saying that for myself, for my needs, subversion's way _is_ less optimal.
No acting required. I don't need to only check out certain trees in my..
[checks] 20MB repo. What I do need is a way to ignore a rotating handful of
files.

------
parfe
Complaining about tools of fairly disingenuous when he didn't make the effort
to learn svn. Also who takes work based on the version control system?
Language I could understand.

edit: replaced "south" with "work" stupid phone.

~~~
dbattaglia
Right, it's definitely surprising that he could decide to outright not take a
job that doesn't use Git. Hell, my last job used Source Safe, it was a please
to be able to use freaking SVN on side projects in comparison at that point!

~~~
dazzawazza
I wouldn't refuse any interesting work based on source control.... even
language. You're hired to do work for a company, if it's interesting do it.

How they manage their code is their business. The OP needs to grow up.

~~~
mansr
I will refuse to work anywhere Clearcase is used for two reasons: 1) the
horrors of using it are unspeakable, and 2) it is a good indicator that the
company will not be a fun place to work for other reasons.

~~~
Roboprog
As long as we're playing the one-downsmanship game, I'd rather use Clearcase
than Serena. At least if there was a big enough _set_ of servers to run the
VOB _and_ view server functions for Clearcase so that it responded. The funky
virtual file system in Clearcase does take getting used to, though.

That said (ramble here...), I've Used RCS, Clearcase, VSS, CVS, MKS, SVN, Git
and Serena. I like Git best, but SVN just isn't all that bad. It works plenty
well enough. Never had reason to use Mercurial yet...

~~~
burgerbrain
I've actually _seen_ SCCS used. Thankfully I myself did not have to, but
needless to say I was rather stunned ;)

~~~
aidenn0
I'm not convinced that SCCS is worse than CVS

~~~
burgerbrain
Perhaps not, but it sure is ancient.

------
pessimizer
He got from

"SVN [is] to Git what Windows 98 was to Windows XP." "SVN is a slightly
crappier version of Git."

to

"SVN is a version of Git in which every time you want to start a branch or
merge it back, you have to sacrifise a young virgin to the source-control
gods."

But I couldn't figure out if he got to "SVN is not a version of Git, just like
Unix is not a version of Windows."

~~~
unwind
It's because the only version control system he's been exposed to before SVN
is Git, so he understands version control in terms of Git. Every version
control system is then like Git, plus some things and minus others. Hence
these descriptions.

At least that was my take.

------
praptak
_"it’s just a folder called “branches” that you manually copy your code into"_

 _FACEPALM._ It is about as accurate as saying that Git does not have
branches, just a "refs/heads" folder that you manually copy your code into.

------
akent
Wow, I'd hate to see what would happen if this guy tried to use CVS.

~~~
kaffeinecoma
That was my thought too. I moved to Git recently, but it wasn't that long ago
that I was rejoicing over how awesome SVN was, simply because I could rename
things (files! directories!) easily and still reasonably track history.

Hmm, was it SCCS or RCS that allowed you to "lock" files and then go away for
the weekend, effectively shutting out the rest of your team?

------
bradfa
My impression is that the issues people have with branching in Subversion is
down to a workflow problem (the people and their actions) more than the
software itself.

Yes, Git does branching and merging way better than Subversion. Git branching
is easier, lighter weight, and it understands playing back revisions to avoid
conflicts very well.

But Subversion isn't a nightmare if you have procedures in place that everyone
on the development team uses and if the development team talks to each other
on a regular basis about it. This whole procedures and talking to each other
thing can be hard for some people and if the mentality of the group isn't good
about it when you join, you'll have an experience like the OP.

~~~
mansr
The whole talking to each other thing also breaks down if the team consists of
thousands of people spread all over the world. Git was specifically designed
with this in mind.

------
numeromancer
I worked once on a project which used a Pick database. If you don't know what
that is, thank the fates. While I worked on it, I dutifully read the mailing
lists and such to learn what I could about this technology. This experience
taught me that every awful piece of technology has a halo of zealots who think
it's the greatest, and is just now (still) on the verge of taking over its
field. And should you hint that there might be anything better, they have a
litany of reasons why _you_ are the problem, because you don't understand it.
The whole thing is about as odd as watching the domestic life of someone who
has married their vacuum cleaner.

Some of the defenders of subversion here reminded me of that experience. The
more truculent defenders slash at those who point out its deficiencies with
remarks about their ignorance of subversion, and if you don't take a couple of
weeks out of your schedule to learn its thorny ways then you deserve your
problems. The milder defenders will equivocate and claim that its just a
preference, and that subversion isn't nearly as painful as long as everyone on
the team always unfailingly follows this list of 178 rules on what not to do.

~~~
Xylakant
My major problem with the people attacking svn is often that they dismiss that
svn has a different set of features that may or may not suit your workflow
better than git's. Every feature of git may be liability in some environments

* I might need a controlled server with an audit-trail where any ability to rewrite history is a liability. SVN wins hands down here.

* I might want the ability to lock binary files since my repo is mainly a set of designs created by the gfx people. SVN wins.

* I might want the ability to mount the repo as webdav folder since I want accountants to store their XLS-Files in there without knowing what's that funky version control system. Git can't do.

* I might want to commit on the road, in the plane, in my cabin in the woods. SVN fails hard.

* On the contrary, maybe my environment is such that the svn server is on the local network and I actually feel uncomfortable with people running around with their laptops and all of my VCS history on them. Git fails hard.

Point is: SVN is a serious VCS. It's better suited to some workflows than
others, same as git. Which tool is better depends on what you're doing and
what the environment you're doing this in. This is what the author of the
original article forgets about. And this an ignorance that I often see in my
fellow developers - and something I can't stand. The most awful piece of
technology might have a spot where it really really fits.

(disclaimer: I currently use git, but have been a very happy svn user for
years.)

~~~
wnight
> Every feature of git may be liability in some environments

Scoff.

> I might need a controlled server with an audit-trail where any ability to
> rewrite history is a liability. SVN wins hands down here.

No, it does not. Nobody can mess with YOUR git repo and while they can make
their repo look like whatever they want, they could do that with any program
by replaying/recording a chosen history. Moreover, git uses the content hash
as an identifier so even if history is rewritten, you automatically know.

> I might want the ability to lock binary files since my repo is mainly a set
> of designs created by the gfx people. SVN wins.

Only binary files? But fine, there are numerous ways you could prevent this
from happening with hooks, but even if someone did slip past and checked in a
change to a file you had forgotten to protect you can see that change and
revert it trivially. Catastrophe avoided.

> On the contrary, maybe my environment is such that the svn server is on the
> local network and I actually feel uncomfortable with people running around
> with their laptops and all of my VCS history on them. Git fails hard.

This strikes me as a made-up fear. Are you this paranoid about browser cache
files from developers browsing the repo? Editor caches? If you've got secrets
presumably they'd be easily leaked from specific single files. It's not like
the attacker would need to achieve a 100% repo duplicate to win - having any
company files accessible is a lose, even if they didn't happen to be sensitive
this time.

But anyways, let's say you've locked everything else down except git. Two
choices, (well, and uncountable others no doubt, but...) break the project
into submodules you would be willing to lose, or use git fully - on a VPN-only
share, such that then the laptop gets turned off the repo goes away.

> SVN is a serious VCS.

Not in the way you mean it, a serious contender. Using it cripples a project
by requiring it to work the SVN way, a slow painful, second-only-to-VSS way.

It's not like it needs to be ripped out as a security hole (that I know of),
but nobody should consider using it for new projects, or should have in the
past few years.

~~~
to3m
"but even if someone did slip past and checked in a change to a file you had
forgotten to protect you can see that change and revert it trivially.
Catastrophe avoided." - this must be a terminology issue? "locking" refers to
a per-file mutex that must be acquired before the working copy can be edited
or committed. It's usually enforced to some extent using the writability
attribute on the working copy files. (Obviously, you can subvert this to some
extent using `chmod +w' or whatever - it's not magic.)

Acquiring the lock may also force the latest version on you in some systems.

This is (these days, anyway) to help people correctly serialise their changes
to unmergeable files.

~~~
wnight
That's handled by not merging changes into the master branch of the master
repo unless you mean to. Anyone gets to see the files as changed, you get to
choose who to listen to.

And, if you forget to pay attention and listen to the wrong set of changes,
you can trivially revert any piece of it.

> this must be a terminology issue? "locking" refers to [...]

I hadn't understood exactly what locking entailed, but I don't think it
changes the issue much.

~~~
to3m
The problem comes if two people have changed the same file in different ways,
and you want both changes. What are you going to do? There's no 'wrong' set of
changes that you can discard. If you lose one and keep the other, that means
somebody's work gets lost, and they have to redo it - so you need to merge.
Will you sit there in Photoshop, carefully pasting together the modified bits?
Will you open 2 copies of 3D Studio or Maya or what have you, and
painstakingly join the two models together?? Well... I'd hope not.

Fortunately, as with many problems, there is a perfect solution, which is to
(try to) not have that problem in the first place. It just needs a bit of
process. Locking is a nice and easy way of introducing a process that works,
and that anybody can understand, all without their needing to know the first
thing about how the mysterious computer-ma-bob actually works. You can do
without it, but it just makes life difficult if the team is distributed,
tiresome if they are not, and error-prone in either case.

I don't have any real idea how you'd go about adding such a thing to git.
Perhaps it wouldn't even be possible. That doesn't make it any less useful,
though. If you don't like the idea of SVN doing something useful that git
doesn't even try to support, consider the two as solving somewhat different
problems.

~~~
wnight
> The problem comes if two people have changed the same file in different
> ways, and you want both changes. What are you going to do? There's no
> 'wrong' set of changes that you can discard.

Well, as you say ...

> there is a perfect solution, which is to (try to) not have that problem in
> the first place

Why are two people both returning the same work? That's a process control
issue you're having and a filesystem hack isn't going to solve that.

> Locking is a nice and easy way of introducing a process that works, and that
> anybody can understand, all without their needing to know the first thing
> about how the mysterious computer-ma-bob actually works.

Not in the slightest. With locking you'd have a confused person trying to save
two hours of their changes, wondering why it isn't working. Eventually they'll
save to a temp file and still have all the same merging work to do, but they
can't do it with the versioning tool so you're pretending it's not there.

> Will you sit there in Photoshop, carefully pasting together the modified
> bits?

Yeah yeah, binary files. No simple merge.

But you wouldn't want the change from the person who shouldn't have made it,
so you wouldn't take it and there wouldn't be a problem. If you do want their
work they'll have to redo it in turn, based on the latest set of changes.

> I don't have any real idea how you'd go about adding such a thing to git.

Simple, you'd have a list of files that shouldn't be edited, or with the name
of who should be editing them. A script would run at checkout and set
appropriate permissions for each. I'm sure there are a few other ways too.

But why? Are your teams really just working on whatever files aren't locked?
Do you really need this tool to do this?

> Perhaps it wouldn't even be possible. That doesn't make it any less useful,
> though.

Perhaps git already does it. That doesn't make it useful.

Do your team communication and synchronization with a communication tool and
leave the filesystem permissions alone. There is no central repo that needs
protection, contention isn't a failure.

> If you don't like the idea of SVN doing something useful that git doesn't
> even try to support, consider the two as solving somewhat different
> problems.

I'm sure there are many valid capabilities of most programs that I don't know
of, or don't fully appreciate the uses for. This seems like a misfeature
though.

~~~
to3m
"If you do want their work they'll have to redo it in turn, based on the
latest set of changes." - and this is exactly the problem that locking is
trying to help solve. I don't see how you can state that contention isn't a
failure, if people are then to have to redo work! These are real people,
presumably working to some kind of deadline. They have better things to do
(and their paymasters have better things to spend their money on) than spend
time redoing changes that they've already done. (It sort of sounds like you
don't think non-programmers would ever have the need to edit a file at the
same time as anybody else might be editing it! Sadly that is not the case...)

As for using an external tool or process to manage the locking, perhaps one
has to actually experience this approach in person to appreciate its
limitations? Or maybe what's in my mind's eye is different from what's in
yours? Anyway, I would not recommend doing this myself.

~~~
wnight
Did you miss my discussion of the problems of permission-based locking? You
dismiss "using external tools" when this is a communication issue, not a
permission issue.

What better achieves the desired results?

1) Having many files, only some of which you can save changes to, but working
on those files otherwise totally unguided when you can.

2) Having many files, all of which you can edit, but only some of which you
have been told via email or IM to work on.

Obviously (I think) #1 is a joke and #2 is the only practical way to go.

> As for using an external tool or process to manage the locking

You're thinking of it from the wrong point of view. From the POV of the
development manager using gantt charts, using the CVS permissions to convey
intent is that horrid external tool.

> I don't see how you can state that contention isn't a failure, if people are
> then to have to redo work!

I didn't say that. I said it's not a failure of the VCS. It's a failure of the
process that led the people to doing two inherently unmergeable things.

As I said in that post, they'd still have done the useless work but they'd
simply have saved it under a temp filename after finding out the file was
write protected. Then - as you read, I said they'd have to do the painful
merge anyways - or watch their work be totally wasted.

> These are real people [...] better things to do [...] paymasters have better
> things [...] than spend time redoing changes that they've already done.

Yeah yeah, I get it. But you're missing the point. I'm saying developers waste
more time doing this your way, despite the locking.

btw, redoing changes they've already done is redundant.

> It sort of sounds like you don't think non-programmers would ever have the
> need to edit a file at the same time as anybody else might be editing it!

Not at all. But the non-programmers are less likely to notice the permissions
and deduce their ultimate reason and impact and do the right workflow thing.

Falling back on the false security of a broken process instead of fixing it is
like using broken crypto - you think you're doing well but you'd be better off
if someone painfully opened your eyes and realized you were totally insecure
all along.

~~~
to3m
This is all so contrary to my experience, that I can only assume we are
actually talking about completely different things. At best, I must simply be
explaining myself poorly. (See, e.g.,
<http://en.wikipedia.org/wiki/Revision_control#File_locking> for a brief
description. I tried to keep my description brief, but perhaps it came too
close to 'cryptic'... apologies...)

Anyway, should you ever meet one of these systems in practice, rest assured
that the problems you suggest will happen, won't.

~~~
wnight
No, I'm pretty sure I'm with you. One person 'checks out' a file to edit and
the rest of the people see it as locked.

But I remember conflicts when working with that style of locking. The biggest
was people forgetting to check their work in before leaving and kept anyone
else from using it, but also people not checking the permissions before
editing, and people who didn't have the lock editing it anyways knowingly
because they had to fix a bug and didn't have time to do it right.

If we were using a dvcs (and no locking mechanism) we'd have been using our
communication tool (then just email and calendaring) more and posting things
like "I'm going to fix bug #... - this is going to require a rearchitecting
foo.c and touching all of foo_*.c and all accompanying headers". This way it's
not preventing someone from working on things, it's warning them of potential
conflicts that would have to be merged.

As long as these conflicts seem small people are welcome to keep developing
next to me. There's no reason to use a giant lock on a whole file. But also,
this schedules my intent in a semantic way - people can see it and say "Whoa,
you'll need to break bar.c as well and Dave's doing delicate work there."
whereas if I'd just locked files nobody would have known to warn me and I'd
have gotten half-way to a working change to be stalled by Dave's project.
Worse, Dave would probably have needed my files to finish his work leading to
a nasty conflict.

------
erikb
It made me irrationally happy to read your blog. Here in Germany it is
impossible to find any company that uses Git or the like. Everywhere you see
CVS (that is the father of SVN) or maybe even NO versioncontrol at all.
Sometimes there is a very modern company that has some part of their code in
SVN (or is a start-up and has no big code base yet). Dreaming about using git
for other things then playing around at home is too fantastic for me. Feel
lucky that you can get your employers to change to git so easily!

Btw. if anybody knows IT companys in or near Berlin, who use modern
technologies like Python or Git, please (please!) tell me!

~~~
cool-RR
Wow, that's depressing to hear.

What happened to "Vorsprung durch Technik"?

~~~
erikb
I would like to know about that, too. I think somewhere there must be some
great, maybe small, companies in Berlin. It is just not that easy to find
them.

------
zwieback
The interesting thing about this otherwise misguided post is that there are
now people who started out on Git who are struggling to adapt the older,
server-based workflow.

It's really not about Git vs. SVN. It's about distributed vs. centralized VCS.
I think programmers are realizing that there's truly an advantage to the DVCS
approach but the discussion quickly becomes emotional and irrational. The net
result of sucks-vs-rocks discussions are just damage to the cause of newer
technologies.

I've used RCSs (RCS,PVCS,VSS(^%$#^$%),MKSSI,CVS,SVN) for so long that the
latest versions of SVN, which support branching (though not so well), seem
very comfortable and luxurious. The Eclipse plugins like Subclipse or
Subversion for updating and merging files make CVS/SVN almost is a pleasure to
use.

However, there are workflows and tasks that DVCS systems support much more
naturally and it's that aspect that should be discussed.

------
sp4rki
So you completely change a way two of your clients do version control because
you're a Git fanboy? I might use Git, an iMac, and Ruby... but I'd never try
to change someones tech just because I prefer a different solution to the one
they have in place and might have fully researched beforehand.

I agree with you deep down... I dislike SVN deeply (and I have to use it
everyday), but you haven't even used it enough to be able to give an informed
opinion on it. Just like Apple fanboys try to evangelize people because
"Windows sucks and Macs are so much cooler and Steve Jobs says so"

BTW, the biggest irony in my opinion, is that you're using Windows, which if
you added Visual Studio to it (yes I know you're a pythonista, not the point)
would mean that SVN is the [sic] BESTEST solution for your source control
needs. Which is also a prime example that the latest technology is not always
the best, and that you should always make this decisions on a case by case
basis.

Also, I'm working on a branch in SVN right now, and I merged a couple of
branches to trunk last friday. This is not rocket science... A good developer
adjusts to the clients needs, not the other way around.

------
gte910h
git svn is the best svn client in the world:

<http://www.kernel.org/pub/software/scm/git/docs/git-svn.html>

You still get to use git, except you push to a svn server (couple of the push
pull commands are different but it works wonderfully).

------
paulasmuth
There is one thing that I find even more useful about git than those "real"
branches: commit messages...

<https://github.com/cool-RR/GarlicSim/commits/master>

~~~
cool-RR
Correct, I don't believe in commit messages. Yes, I know this is an unpopular
opinion. I might blog about it in the future, making the case for it.

~~~
mkopinsky
Someone who "doesn't believe in commit messages" thinks his opinion on VCS is
worth something?

~~~
cool-RR
Save your contentless contradictions for my next blog post.

------
sscheper
Is Git 100% social/public? Can code be private? And last question: is it
secure enough to where enterprise companies (not just tech hipster startups)
use it?

~~~
burgerbrain
Nothing about git makes it either "social/public" or private. You can use it
yourself entirely on our own workstation, you can use it on a company server
only your devs have access to, and you can of course make public repos on your
own hardware or with hosted solutions such as github.com.

Git is also arguably more secure than many other VCSs since it (in a very very
small and generalizing nutshell) works by creating a directed graph of SHA
sums. You can't change a file and propagate those changes to other people
without everyone being well aware of what has been done. Not unless you can
compute _useful_ code that collides with existing code... check out what linus
has to say about that improbability some time^ ;).

No, security shouldn't be the issue for enterprise companies, though
scalability is often cited as a potential issue. If you currently use perforce
to a heavy degree, you might have some issues with going to git. This is not
to say that git cannot work for very large companies, it probably just isn't
going to work well if you put every project in your large company in a single
one or two repos (as many companies do with perforce). It'll handle large
projects fine however, it handles the linux kernel like a breeze.

^ [http://osdir.com/ml/version-
control.git/2005-06/msg00583.htm...](http://osdir.com/ml/version-
control.git/2005-06/msg00583.html)

~~~
exDM69
Using a giant repository (like some people do with perforce or even svn) is
not a smart move with Git. In fact, I think that it's even mentioned (or at
least used to be) in the Git documentation. I've read more than one
disgruntled blog post about someone who dumped their entire 60 gigabyte
Perforce repo (full of binaries) to Git.

These days you can use git submodules which work quite nicely.

