A Git user’s first (and hopefully last) foray into SVN-land
blog.garlicsim.org
blog.garlicsim.org
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 :)
s/older/unfamiliar/
I absolutely agree with that substitution. You can (and I certainly do) see the exact sort of thing going on in the reverse direction with various technologies. I'm guilty of it myself. That's why I find it interesting.
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.
"A good developer can work with crappy tools and make great things."
So what exactly is your point here?
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.
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.
I've been doing this for almost three years now and haven't had any major problems yet.
Except for: Merging. Since SVN 1.5 (or so) merging in SVN got less painful because from then on when merging, SVN tracks which revisions have already merged from one branch to the other.
AFAIK it does so by saving the merged revision ranges into the svn:externals as meta data which can then be used for the next merge operation to prevent changesets to be merged twice into the same branch.
However, when you merge with git-svn this information will not be recorded, so the next person merging with SVN will probably run into problems.
Solutions:
a. you don't merge with git-svn
b. anyone merging with SVN explicitly tells SVN which exact revisions to merge
You can still use local branches of course and as long as you only merge from one local branch to the other with Git, there won't be any problems.
At my work place we luckily pretty much only have trunk and very, very short-lived branches, so this isn't an issue for me.
A correction, while the fact that SVN creates a copy of the entire code, when you create a branch, it isn't as horrible as it sounds, from the SVN documentation:
"When you copy a directory, you don't need to worry about the repository growing huge—Subversion doesn't actually duplicate any data. Instead, it creates a new directory entry that points to an existing tree. If you're an experienced Unix user, you'll recognize this as the same concept behind a hard link. As further changes are made to files and directories beneath the copied directory, Subversion continues to employ this hard link concept where it can. It duplicates data only when it is necessary to disambiguate different versions of objects."
( http://svnbook.red-bean.com/en/1.5/svn.branchmerge.using.htm... )
That being said, the day my company will finally switch to Git will by a happy day... :D
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?
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
On the whole, I find git-svn much nicer to work with than raw SVN. I can have local branches for work in progress, merge/rebase and with/onto trunk with ease, queue up multiple commits before pushing, work offline, etc. Using plain SVN, by comparison, feels like driving blindfolded in reverse with the handbrake on. CVS is like additionally having your head in a bucket of water.
At some point down the line we swapped the server over as well.
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 :)
Suppose that while developing a feature, you realize that a piece of code is buggy. In your view of the world, where everything is linear, either you drop everything you're doing and fix that bug, or file a bug with the tracker, deferring it until someone has time to fix it.
But morally, the second one is just a branch--time in this case isn't linear. You (or someone else) will have to change contexts at some point and fix the bug. If it's after your feature has been committed, then you have to do it on code which may have churned quite a bit since you filed the bug.
So if you used branches, you would just create branch for the fix. If it gets committed into master before your feature, you could obtain upstream changes. If it gets committed after your feature, you can use rebasing to replay that work on top of the significantly changed code.
If you need to do big arch changes, you still do them in bits such that every build isn't broken. You just do them in a branch, so that nobody else sees them until they are completely ready.
Note also that, with git's powerful tools, you have the option (which is usually taken, these days) to rebase your branches into master, not merge them. So, when you published your changes to the world (git branches are local, nobody else can see them) you could still show the world a linear line of development if you so pleased.
So it may not be a "this is better than this" mentality, but you definitely do lose a significant amount of expressiveness and flexibility for no reason. Branches are painless (in git) and certainly not a waste of time (in that they actually streamline the development process). Can you describe the situation in which you thought that was the case?
Others may have different experiences, especially if they work on large teams.
The only reason I can see to "branch" is when you deploy code, make a copy of it in the repos, so that you can fix any bugs off it quickly.
Branches are feature isolation. For every different feature you add or bug you fix, you, personally and locally, create a branch to do so. If you think that is a lot of branches, you simply don't have the appropriate mental model. If you continue to think of a branch as "making a copy of it in the repos" (what does that even mean??) then, it's... just not the appropriate way to think about it.
Anyway, I'm not going to continue to have this conversation, since it's just not worth it. I just hope I don't have to work for a company that thinks that "branching is bad", but at least if I do they will never know that I am actually using features of my version control system (gasp!).
Some authors probably have tons of concurrent drafts of a novel they're writing. But I'll bet most have a single draft.
I'm afraid (to a fault), I am primarily a lone developer so this is the angle I come at these things from...
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).
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.
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.
That makes absolutely no sense whatsoever, unless it is a troll. Nothing can be "good enough" simply by virtue of not being something else.
Change any of that, and you need a better technique.
There are lots of different ones, and switching between them is a mind-bend, so folks gripe a lot. But you'll likely have to learn one sometime, probably sooner than you'd like.
Please don't be the guy that gripes and drags his heels. There are legitimate reasons to need source control. Your personal convenience is one of the decision factors, but a very minor one.
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...) 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... 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... 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 .
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.
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.
...a .gitignore file in the same directory as the path, or in any parent directory, with patterns in the higher level files (up to the toplevel of the work tree) being overridden by those in lower level files down to the directory containing the file.
A global .gitignore feature in the toplevel of the work tree is just one way of using the .gitignore feature.
2) If character count is important,
svn ps -R -F i .
edit: replaced "south" with "work" stupid phone.
How they manage their code is their business. The OP needs to grow up.
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...
I've only read of the "original" SCCS, but never seen it in the wild. Did it actually work well for its practitioners? (e.g. - RCS, for all its weaknesses, works well enough for a small project and small local, trusted, group)
My alarm bells ring every time I hear a company using CVS or Perforce or something even worse.
Sometimes you just gotta suck it up, though. I have to use Perforce and Google Repo at work and it not only sucks, but is making me lose valuable coding time daily when I have to use an inferior tool to what's available out there.
"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."
At least that was my take.
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.
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?
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.
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.
* 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.)
Um. git-svn and a usb key neatly sidestep that for anyone who wants to take your IP. If someone can read your IP, they can pretty much extract it. Sorry.
It's also worth noting that hg is better at the immutable history idea, so if that's a criteria for adopting, hg should be looked at.
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.
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.
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.
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.
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.
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.
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.
Anyway, should you ever meet one of these systems in practice, rest assured that the problems you suggest will happen, won't.
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.
Btw. if anybody knows IT companys in or near Berlin, who use modern technologies like Python or Git, please (please!) tell me!
What happened to "Vorsprung durch Technik"?
I grew up in Germany but spent most of my working life in the US. My experience is that the overall mentality of engineers in Germany is somewhat different, more of a focus on process and less on experimentation, but it's a matter of degrees. I'd be surprised if the percentage of shops using no version control is higher in Germany, though.
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.
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.
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).
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...
These days you can use git submodules which work quite nicely.