Subversion 1.8 Released But Will You Still Use Git? 378
darthcamaro writes "Remember back in the day when we all used CVS? Then we moved to SVN (subversion) but in the last three yrs or so everyone and their brother seems to have moved to Git, right? Well truth is Subversion is still going strong and just released version 1.8. While Git is still faster for some things, Greg Stein, the former chair of the Apache Software Foundation, figures SVN is better than Git at lots of things. From the article: '"With Subversion, you can have a 1T repository and check out just a small portion of it, The developers don't need full copies," Stein explained. "Git shops typically have many, smaller repositories, while svn shops typically have a single repository, which eases administration, backup, etc."'"
Major new features of 1.8 include switching to a new metadata storage engine by default instead of using Berkeley DB, first-class renames (instead of the CVS-era holdover of deleting and recreating with a new name) which will make merges involving renamed files saner, and a slightly simplified branch merging interface.
yup (Score:3, Funny)
short and simply, yes. If Linus says so, we obey.
mkdir FP (Score:2)
git --bare init
github (Score:2)
I really started using github regularly at the same time that I started using github.
It's grown to so much more than the underlying version control software.
Re: (Score:3, Insightful)
Really?!
Re:github (Score:4, Funny)
Really?!
He said what he said.
Re:github (Score:5, Funny)
Pfft. I've been using Github for decades before I started using github.
Re: (Score:2)
I didn't notice what I did until I read your reply.
Re: (Score:2)
Re: (Score:2)
I would imagine a shop with that requirement would install an in-house manager for Git repos.
One size does not fit all but it's nice to have a solution that can be fitted easily.
Re:github (Score:4, Informative)
You don't need to use github to use git, bit if you really like github, you can run it on your own servers, there is an enterprise version.
Different strokes for different folks (Score:5, Insightful)
For some development projects / communities, where everyone is independent and rarely connected to a central point, the distributed VCS make more sense. The downside is that you have to rely on developers to push their changes to some "master". On the other hand, it means they can work offline / disconnected.
For the less technical users, centralized VCS like SVN makes more sense. As long as you can get them to commit the changes, you're ensured that those changes are now on a server/machine that is getting backed up and taken care of.
Re: (Score:2)
Re:Different strokes for different folks (Score:5, Interesting)
I find that using git-svn [kernel.org] with a central SVN repository results in a very nice workflow. In my local git repository, I'm free to develop in a nonlinear, exploratory fashion. At logical stopping points, this work gets neatly reconciled with reality in the form of sensical SVN commits. It's the best of both worlds, and allows me to do useful work even on an airplane.
Re:Different strokes for different folks (Score:5, Informative)
Why? There's a LOT of places where version control is very useful outside of software development.
Keeping track of documents, for example - marketing folks run through a lot of variations of a theme and having a repository of older versions of the document is handy. Because otherwise they're going to do it themselves (you'll find documents with timestamps on them for that reason).
Sysadmins often use VC on their configuration files as well (I've known some to store their Cisco hardware configuration files in VC as well). Serves as a backup (the repos are backed up with the regular source code backup), as well as an "oh shit the switch went down what's the last configuration we have" panic. Instead of hunting through endless wads of files (did I put it here last time? Or is it over there?) you just grab the latest from VC, maybe go back a revision and use that.
Version control is extremely helpful for a lot of things - being able to hold the latest and previous versions of something in one spot is surprisingly helpful for a large number of instances.
Re: (Score:3)
Sysadmins often use VC on their configuration files as well
Definitely. etckeeper (can be configured to use one of serveral VC systems) is excellent for this job and I use it so when I do something that breaks the server, rolling back the configuration to a known good state is trivial.
Re: (Score:3)
Nice improvements (Score:3)
Going through the article it looks like a nice set of improvements. I expect that subversion users will be pleased with both the current improvements, and what will be built upon them in the future.
Among the useful improvements noted [developer.com]:
One of the area where robustness has been improved is in the storage of metadata. SVN now tracks the moves of working copy items. Stein noted that the harder part is getting the rest of the system to recognize the moves, and that work is ongoing. He explained that from a historical perspective, SVN didn't "move" items per se. Instead, the item was copied to its new location, and deleted from the old.
"This is problematic (for example) because if an edit comes in from the server for that deleted item, then we don't know what to do with it," Stein said. "For a moved item, then we know the edit should probably be applied to wherever the thing was moved."
But can SVN merge a branch yet? (Score:2)
Re: (Score:2)
Re:But can SVN merge a branch yet? (Score:4, Informative)
Re:But can SVN merge a branch yet? (Score:5, Informative)
Pardon me reposting part of what I wrote above, but I think it explains what he was talking about:
It's ok to create a branch (say from trunk), work on the branch, and even update it from trunk, but you're pretty much limited to a one-time reintegration merge from that branch back to trunk. You can't easily go back and forth, choosing to put one new thing from trunk into branch and vice versa. That becomes a serious pain if, for example, you use trunk for new development and a release branch on the side. The natural way to work is, if a bug is found in the release, fix it in the release branch and then merge that one change back into trunk. Similarly you may fix a bug in trunk and realize you should also merge it into the release. Svn doesn't really let you do that, so I have to tell people to always make the fix in trunk and merge that one change to the release.
Re:But can SVN merge a branch yet? (Score:4, Insightful)
The natural way to work is, if a bug is found in the release, fix it in the release branch and then merge that one change back into trunk.
I hate this version of work......I have some coworkers who always do it. They occasionally forget to merge something back into head, which means they have to revisit the same problem in a few months. If you're going to miss a merge, it's better to miss the merge back into the branch, rather than into head; because as long as it's merged into head, it'll be fixed eventually.
Re: (Score:3)
I hate this version of work......I have some coworkers who always do it. They occasionally forget to merge something back into head, which means they have to revisit the same problem in a few months.
I've found that a good way to prevent that from happening again is to summarily execute the offender and hang his or her corpse from the flag pole as a reminder to others.
There's also Murphy's Law corollary that says that no matter what your preferred workflow is, there will come a day when doing it differently is necessary or expedient. For example, trunk may be temporarily unstable, which means you wind up fixing the bug on the branch. Of course trunk is never supposed to be unstable, but there are a lo
backwards bugfix (Score:3)
If you find a bug on a release, you fix it on the trunk, test it on the trunk for a while, then merge it out onto the (supposedly stable) release.
That way if it turns out the fix is bad, you haven't messed up the release more than it already is.
Re: (Score:3)
Yes! That is the biggest problem with Subversion, and I hope that 1.8 fixes that as promised (although they're only promising partial support right now).
At work one of my side jobs is managing the VC for our small (5 person) dev team. For a small closely knit team centralized VC is fine, but the very limited merge capabilities of svn drive me nuts. It's ok to create a branch (say from trunk), work on the branch, and even update it from trunk, but you're pretty much limited to a one-time reintegration merg
Re: (Score:2)
This limitation has been lifted in 1.8. As long as you use no merge commands more complex than
the merge works in either direction and should never flag spurious conflicts caused by changes being applied more than once.
There were ways to work around deleting a reintegrated branch [red-bean.com] in 1
Re: (Score:2)
Sparse checkouts (Score:5, Informative)
Although I'd argue that if this is a common problem then you probably have several sub-projects.
It's GIT for OSS, SVN for Enterprise. (Score:5, Insightful)
-SVN has much better visual tools and is simpler to operate
-SVN has a simpler merge policies which are friendlier when there isn't a central person pulling the changes.
-SVN is very friendly for projects with a lot of binary objects (ie videogames)
-SVN allows different people to work on different directories individually, GIT doesn't.
-SVN has fine grained permissions, access and authentication controls, very useful when parts of your project (ie, APIs) are under NDA or you don't want them to leak.
They are different systems with different scenarios in mind, comparing them or claiming that GIT is killing SVN is just ignorance.
Re:It's GIT for OSS, SVN for Enterprise. (Score:5, Informative)
Actually... git fits the workflow better than svn. I have to manage a project that spans multiple institutions and two continents. Instead of forcing everyone to use VPN while they develop, they only need to use VPN to push to the official repository.
What? I use SourceTree on OS X and my coworkers on Windows like TortoiseGit. Also there is "git gui"
What? I don't think you understand how git works.
Not necessarily. We use both svn and git to manage very large BLOBs and I haven't seen any noticeable differences. I have people that version control gigabytes worth of design documents that are stored in binary format and I haven't heard any complaints from them.
We used to think this was a big deal, but the advantages that git has over svn more than made up for this.
What? First not by default. The most popular method https+ssh does not. You can use Crowd to make it a little easier.
Whereas in git I use gitolite. I manage their public keys and assign privileges based on the public key. Keep the NDA (or more importantly ITAR) in a separate git repository which makes life easier all around and satisfies the regulators too. They weren't too comfortable with trusting the single repository to handle the compartmentation correctly.
I operate both SVN and GIT systems. My anecdotal evidence show that most of my projects left SVN and went with GIT due to its distributive nature. We have operational processes in place that eliminates the need for physical enforcement of a centralized repository. As an extra bonus, my co-developers like the ability to check in while they develop and then push the changes once they are confident that it won't break the build on the official repository.
Re: (Score:3)
I'm sure this will be an unpopular opinion, but I seriously loath git. Its distributed development model is nice for certain types of projects, but aside from that, doing almost anything in git is more complicated and more work than doing the same thing in svn.
I think the fundamental architectural flaw in git is that it insists on a 1:1 correspondence between repositories and working copies. If you want a working copy, you absolutely must have a unique repository to go along with it, and that repository m
Re: (Score:2)
Pull requests work great for many team projects where developers are not familiar with the entire codebase. The codebase can be split into separate repos with different permissions. When a developer makes a change to part of the code they're not an expert at, they create a pull request and a member of a team who does know that piece of code reviews and merges. This is much easier than passing around patch files like you have to do with an SVN repo with strict permissions. It's also much easier for interns and contractors to work on code, since they can clone the repo and create a pull request to merge their changes without having write access to the repo.
How is that different from creating a branch for the developer/contractor/intern and only giving them write access to their branch, and when complete having someone else merge their branch back into master after doing any code review?
Re:It's GIT for OSS, SVN for Enterprise. (Score:5, Interesting)
The idea of Git eludes you. You don't structure Git projects in a giant directory tree.
The first problem here is that you need to decide, up front, what your structure should be. For pretty much any large project that I've worked on, the correct structure is something that's only apparent 5 years after starting, and 5 years later is different. With git, you have to maintain externals if you want to be able to do a single clone and get the whole repository. Atomic commits (you know, the feature that we moved to svn from cvs for) are then very difficult, because you must commit and push in leaf-to-root order in your git repository nest.
1TB repository? (Score:3)
Who has a 1TB repository? Even 200GB is 15 shades of ginormous.
Re:1TB repository? (Score:5, Funny)
Who doesn't store their DVD collection in source control?
Re: (Score:2, Funny)
Only for George Lucas Star Wars revisions...
Re: (Score:2)
Lucas doesn't need version control for his Star Wars changes. Once he's got the new one, he throws all of the old versions away.
Re:1TB repository? (Score:4, Informative)
Lots of places really.
Some companies use it for versioning of content as well as just source code and that may mean archiving raw versions of said content such as images, 3D art assets, uncompressed audio and so forth.
Re:1TB repository? (Score:5, Informative)
On the last games I worked on, a minimum initial sync to build was around 50GB, full sync was over 150GB (MANY different language versions of NIS movies.) I have no idea how big the revision database was but I'm going to guess freakin' huge with over 600000 commits during the project. The BlueArc backing Perforce was bretty large.
Git would explode in a cloud of fail if you tried to do anything like that, in my opinion it's for toy sized projects.
Where I work now (at a semiconductor company) the people calling the shots switched from Perforce to Git and it truly sucks. There's over 400 repositories to build the project managed by a nasty set of shell scripts. What I wouldn't give to have a single place to manage all of the changes.
Game programmers who need Art! (Score:5, Informative)
I worked in game programming several years back, and 1TB was quite reasonable. Branching meant IT would bring everyone a new hard drive to store the new branch on.
IIRC the client for one of the MMOs I worked on was a 20 gig download. The source code that actually went into that... was big, but couldn't possibly have been a gig of raw text before being compiled; the art on the other hand, was sliced, diced, squeezed and compressed to get it down into that small of a download. Art Is Huge. Especially art in the raw forms -- even if the final game art is going to be some horribly compressed format to save space, artists want to record the initial sound files in pristine high bitrate forms, and want to do the initial drawings in zillion-pixel-wide, maximum-color-depth formats, and then compress later. The intro-video that nobody watches alone probably took up more space in the repo than all of our source code files, because it was rendered for impossibly good monitors. So, in our repo, we have both the compressed MP3-low-bitrate voiceovers that go into the game, and also the uncompressed-perfect-form from the recording sessions (just in case we want to recompress to MP3 later so we can have a higher bitrate... or maybe we'll swap to using ogg next year... or just for historical interest? it's a repo, you check stuff in...) And similarly for the textures -- the original photoshop files at maximum size and color depth are gorgeous... and then there's the smooshed version you get on your computer. But we have to store the maxumum size one, because that's the one that we're going to edit if we make a change! And it's version-control, so the repo has this hard-to-compress binary (trust me, photoshop files don't compress nearly as well as python files), possibly in a dozen different versions because all of your art got reviewed and edited as it passed through various layers of management and licencees... And then of course there's video too -- cutscenes and intro video and such.
There's no chance that you could get a repo like that to work on git. We used perforce rather than svn; perforce is (or at least was at the time) the popular tool in the gaming industry for source control (it's expensive, but stable and has good support for massive repos), but I can see lower budget places going for svn. Git just isn't designed for huge repos full of binary blobs.
SVN is better if you don't know Git (Score:2)
I worked in game programming several years back, and 1TB was quite reasonable. Branching meant IT would bring everyone a new hard drive to store the new branch on.
Git just isn't designed for huge repos full of binary blobs.
Apparently neither is Perforce/SVN. More to the point, I am aware of no sound basis for that statement. Git does binary diffs just fine, and compresses the data when reasonable, and stores file deltas where that is more efficient. Cherry-picking a change to a binary file sounds painful, but it's likely that's a stupid idea that would not be tenable in any RCS. If there is some secret limitation to how git stores files, I'd love to hear about it. My suspicion is that this "svn is better for large repos" idea
Both Have Their Purposes (Score:4, Interesting)
I started using Git last year for my personal projects. It's a fantastic platform for coding as a social-network. I love that I can grab code I need from other developers around the world, tweak it, and send it back with a few suggestions. I love that I can follow other projects without having to get involved. Git is awesome.
That being said, we still use SVN for our internal development. The WYSIWYG interface of Tortoise is simply really comprehensive. I realize that Git offers more options, but if those options aren't available with a simple right-click, then I don't have the time for them. Tortoise SVN makes everything readily available, while Git makes me run to the command line too often.
Re:Both Have Their Purposes (Score:5, Informative)
TortoiseGit? [google.com]
Re: (Score:2)
Do you also like the tree conflicts you get when moving directories around in your project? Those are my favorite thing in SVN. In theory, they've made this better in the new version but I'll believe it when I see it myself. That's something about SVN that just really pisses me off.
Re: (Score:2)
Tree conflicts [fu-berlin.de] are inherent to any version control system, not just Subversion.
People complain about Subversion's tree conflict handling a lot. I believe this is because development work done so far was only about detection of t
Re: (Score:2)
Git is auto-backup (Score:4, Insightful)
Re: (Score:3)
For small repos that's fine, it's a feature. For large repos it's not fine, it's a serious problem. I literally cannot fetch the Android-x86 repo. git won't just finish sending the old stuff if new stuff has appeared since your last attempt to fetch the repo.
This wouldn't be as big a problem if people didn't think that git access was a substitute for a tarball, so that if you just need to build the fucking code you can do so.
Re:Git is auto-backup (Score:5, Informative)
For small repos that's fine, it's a feature. For large repos it's not fine, it's a serious problem. I literally cannot fetch the Android-x86 repo. git won't just finish sending the old stuff if new stuff has appeared since your last attempt to fetch the repo.
This wouldn't be as big a problem if people didn't think that git access was a substitute for a tarball, so that if you just need to build the fucking code you can do so.
Use 'git clone --depth 1' if you only want the most recent revision. It will allow you to update it from upstream but obviously you won't be able to go back into the history.
Re: (Score:3)
Use 'git clone --depth 1' if you only want the most recent revision. It will allow you to update it from upstream but obviously you won't be able to go back into the history.
this is very useful information; thanks. too bad git doesn't do this first, and then fill in the history later. that would make it dramatically more usable for the average human.
bazaar (Score:2)
both actually (Score:2)
For personal stuff, or things I intend to share haphazardly or widely, I go git all the way. Git is great for when I need to work disconnected and still keep revisions. Its simple, its fast, its easy to make a quick repo, so quick sometimes I make one for things I wouldn't otherwise, because even if it never gets used again, the overhead of turning a directory into a git repo is trivial.
That said, there are times when i have other requirements. Things that are going to need to be tracked long term, be share
Pristine copies (Score:2)
But definitely the ability to check out just a few folders or files is an advantage of CVS and Subversion. Git forces everything to be cloned although
Decent comparison (Score:5, Informative)
I'll just leave this here so people get to see a comparison that's actually useful.
https://git.wiki.kernel.org/index.php/GitSvnComparison [kernel.org]
Git not good for big assets (Score:2)
Hit me baby one more time (Score:2)
We use Microsoft VSS. No, don't hit me!
I get punched in the face several times a day already.
Misleading summary (Score:5, Informative)
I'm a Subversion developer and would like to clarify this bit of the summary:
The "new metadata storage engine" probably refers to FSFS which has been the default repository backend since Subversion 1.2. FSFS has been improved since then, and 1.8 contains some new improvements (such as directory deltification) but does not add a new repository backend. The BDB-based backend is the one from Subversion 1.0 and is rarely used these days.
Subversion 1.8 doesn't contain support for "first-class renames". Renames are still modeled as copy+delete [apache.org], with special annotations. The working copy is so far the only part of the system which is aware of moves. There are plans to make other subsystems aware of moves in future releases. Also, while tree-conflicts involving local moves can now be auto-resolved after 'svn update', 'svn merge' mostly behaves as it did in 1.7, expect there is no need to use the --reintegrate option and tree conflicts are now flagged if a directory was renamed or deleted on the merge source branch. Whereas Subversion 1.7 would unconditionally perform the deletion in the merge target.
Too little, too late (Score:2)
first-class renames (instead of the CVS-era holdover of deleting and recreating with a new name)
Has SVN missed the boat? Basic features that were desirable 10 years ago lead people to use BitKeeper, arch/arX/tla/Bazaar, and eventually Hg, monotone and Git. (I guess some folks were using Darcs too). Now that people have tackled the learning curve and the lack of tools. These days many of these alternatives to CVS and SVN have support in numerous IDEs and desktop environments
It is probably great news for people still using SVN. But why should we keep going in that direction? I also wonder why Perforce i
Perforce is free for small-enough user bases (Score:2)
It's enterprise software and we were actually informed by Perforce after maybe 10 years on a license that since our user base is so small we can use it for free. I think the cutoff is based on the number of licenses per server. I've never needed my own personal SCM, but I'd go w/ Perforce if I never needed one.
Re:GIT sucks on windows (Score:5, Interesting)
If you live in linux land and love using only command line, then GIT is fine. On the other hand, if you want to grab the latest code, make a change and commit, GIT sucks. It's especially true if you're using Github. Having to rebase is tiresome, especially on windows. The times I've contributed to OSS projects that used GIT, I spent 5 minutes make the code change and 30 minutes rebasing. For comparison, with SVN, I spend 1 minute to do update and 5 minutes to make the code change.
What about Mercurial? (you know, the DVCS that fanbois dis because it's not used by Linus the ultimate cool kid). I'm considering switching from Subversion to something else for my team at work, but the Git UI is awful. I've heard Mercurial is better, including its GUI integration (e.g. Tortoise).
P.S. To put a little damper on the flame war that this will ignite, I swear that personally I would give my left kidney to crawl over broken glass for the privilege of reading man pages all night just to be able to do the same thing with Git that I could figure out in 5 minutes with any other version control system. However, other people on my team are very good at what they do (Ph.D.'s working on signal processing) but are not quite as enthusiastic as I about the broken glass.
Re: (Score:2)
What about its UI is awful? Is it because it is command line based that makes it awful?
I think the real problem is that people approach Git thinking it's like SVN, and when the SVN way of doing things doesn't work they get frustrated and proclaim it to be awful.
Re: (Score:2, Insightful)
Git is full of appalling bad usability decisions. Like requiring git commit -a, which for Mercurial would just be hg commit as a sane person would expect. Git fans spout a bunch of drivel about "staging area" to justify it, but it can't be justified. Warts like this are strictly a geek endurance test, to learn where your pain threshold is. If it is sufficiently high then you are cut out to be a Git nerd forever.
Mind you, Git is wonderful compared to Subversion which just can't do the things you need to do.
Re: (Score:2)
Why can't it be justified? Not every change needs to be committed, I've had running debug changes that have never been committed because they don't need to be, and the staging area lets me ensure only the necessary changes get checked in. It also lets me prevent them from ever being a part of any commit, so I d
Re: (Score:3)
Whether you prefer to include all modifications in a commit is a workflow driven decision. I like the way git's default pushes me to review each change once before it goes in. Going through a round of "git status" and reviewing what's staged is a good coding practice when many people are going to consume what you commit. And that's exactly the situation git's defaults are setup to support--an environment where mistakes are going to be consumed by a lot of people.
You seem to feel that your way is the One
Re: (Score:2)
That was my first reaction to git (coming from svn). But if you use a nice GUI tool to commit, not only can you pick and choose your files, you can pick and choose chunks of files or individual lines to commit.
Generally, I make a bunch of changes (often unrelated), then eventually I get around to checking them in. On the command line (git commit -a, svn, etc) I would update everything at once. With a git gui, I can break it up into individual commits. And work in progress, debug code, unrelated chang
Re: (Score:3)
What about its UI is awful? Is it because it is command line based that makes it awful?
I think the real problem is that people approach Git thinking it's like SVN, and when the SVN way of doing things doesn't work they get frustrated and proclaim it to be awful.
I use SVN, and I've used Git. I realize they're different and I expect differences. Yet, little things like Git not tracking empty directories drive me nuts. A VCS of any kind should be able to store a directory structure without a problem and before files are added to it; yet Git fails that very basic functionality. Staging is a nusance, but on that can be lived with, though I'm sure it makes complications that will itself cause bugs.
On the other hand, Git just doesn't do permissions. So everyone has ac
Re:GIT sucks on windows (Score:4, Interesting)
What about Mercurial?
Mercurial matches Git in functionality and performance, but completely blows it away in terms of usability and elegant design. Without the Linus factor, everybody would be using Mercurial, not Git. I tend to use Mercurial a lot anyway. One weird and useful thing I do with Mercurial is make a Mercurial repository inside a Git repository, to track files I don't want in the Git repo but still want to track and keep in the same directory.
Mercurial is underrated (Score:3)
What about Mercurial? [...] I'm considering switching from Subversion to something else for my team at work, but the Git UI is awful. I've heard Mercurial is better, including its GUI integration (e.g. Tortoise).
In UI terms, there are respectable GUIs available for both Mercurial and Git these days. I’d say the biggest difference is in the CLI interaction, because the usability of Git is poor even in its native habitat on Linux, and on Windows you're basically stuck with Git Bash, which is a rather glitchy emulation of a Linux shell that IMHO is very irritating to use. Hg is much simpler and less cluttered.
In terms of functionality and the underlying models for how the system works, I’d say there are a
Re: (Score:3, Interesting)
TortoiseGit is a flaming pile...it tries too hard to look like TortoiseSVN, and so it just ends up being confusing. There are a number of alternative gui git clients for windows, of which Sourcetree [sourcetreeapp.com] is my current favorite, but not by much (I don't like it as much as either TortoiseSVN or TortoiseHg).
To the gp, if you're on windows, I'd give mercurial the edge, based on both UI and general mindset. Git is very much a product of linux, and so it makes some assumptions that aren't correct if you're on window
Re: (Score:2)
TortoiseGit is a flaming pile...it tries too hard to look like TortoiseSVN, and so it just ends up being confusing. There are a number of alternative gui git clients for windows, of which Sourcetree [sourcetreeapp.com] is my current favorite, but not by much (I don't like it as much as either TortoiseSVN or TortoiseHg).
To the gp, if you're on windows, I'd give mercurial the edge, based on both UI and general mindset. Git is very much a product of linux, and so it makes some assumptions that aren't correct if you're on windows. On the other hand, github is both amazing and unique (bitbucket tried to do the same thing for hg, but it's not nearly as nice a social scene). And if you're trying to develop marketable skills (probably a good idea in our industry), git experience will most likely take you farther than hg experience.
Thanks for the advice. I'll look into some of the Hg GUI stuff you mention. Unfortunately we're stuck w/ Windows clients as that's what our cross-dev tools run on. I've played w/ Git, including TortoiseGit and came to similar conclusions as you. It seems to me like Hg gets short shrift.
Re: (Score:2)
We've found that Smart GIT/HG [syntevo.com] works really well for our GUI repo needs.
Re: (Score:2)
Fwiw, FogBugz released Kiln Harmony that allows devs to use either git or hg.
http://blog.fogcreek.com/announcing-kiln-harmony-the-future-of-dvcs/ [fogcreek.com]
Re: (Score:2)
Re: (Score:2)
Re:GIT sucks on windows (Score:5, Informative)
Re: (Score:2)
What's so difficult about doing these things on Windows? It's the same process as OSX or Linux. And why do you need to rebase so much?
Re: (Score:2)
Rebasing is extremely handy when you have multiple branches being developed. Whenever a branch is merged, you rebase the other branches so that the merged feature gets pulled into each branch.
Re: (Score:2)
on the other hand you should never have to ask such a question as "why do you need to rebase so much". It's there, it's a feature of git, there should never be a restriction such as "yeah, you can use it, but not too much".
The reason to use rebase is simple:
To avoid clogging up the revision history with those moronic "Merge branch 'master' of [url here]" commit messages.
As I found out the hard way.
Re: (Score:3)
...Having to rebase is tiresome...
Versus Subversion where you *can't* rebase. Instead, just let everything degenerate to the point where contributors habitually build up massive diffs that conflict with every other team member, interspersed with episodes of panicked committing, build breakage and mutual recrimination just before planned release dates. Been there.
Re: (Score:2)
I've seen that happen with git.
git "encourages" developers to share often. It doesn't mean that they will.
Re: (Score:3)
I have to do periodic merges between CVS branches and I have to set aside several hours to do it thanks to all the tagging that has to go on before and after the merge to ensure it happens properly. The fact it takes so damned long it discourages me from doing it more often.
Re: (Score:3)
If you'Re using Windows, just try SourceTree.
Re:GIT sucks on windows (Score:4, Informative)
Having to rebase is tiresome, especially on windows
git config branch.autosetuprebase always
Or add --global to apply this to your personal settings. I don't understand why they didn't make this the default behavior, but there you have it. (And why "especially on windows"? What's different about doing it on windows?)
Re:SVN sucks on windows (Score:5, Insightful)
Care to point to specific bugs? We've been using SVN for years and never seen these problems.
Moreover, since SVN is client-server, why would a buggy client cause datacorruption in the database? Are you implying there are major bugs in the svn server?
without backup, your claims are just FUD...
Re: (Score:3)
Care to point to specific bugs? We've been using SVN for years and never seen these problems.
I've had the same experience. Yet a cow-orker next to me constantly has serious problems with SVN.
They're just reckless. They damage the metadata in their working copies, forget to svn add|move or whatever, do merges wrong and then blame subversion when all that accumulated damage bites them in the ass.
Re: (Score:2, Funny)
That guy's misuse of SVN is a concern, but far more disturbing is the fact that he seems to be orking cows in the workplace.
Re: (Score:2)
Re:First post! (Score:5, Funny)
cat ./slashdot/posts/44049461.txt | sed 's/First/Second/g' | sed 's/muajaaa/bwaaa/g' > ./slashdot/posts/44049461.fixed ./slashdot/posts/44049461.fixed ./slashdot/posts/44049461.txt ./slashdot/posts/44049461.txt
mv
git add
git commit -m "Fixed that for you!"
Re:First post! (Score:5, Funny)
The International Feline Association awards you with today's "Useless use of (a) cat"-award. Meeeeow!
Re: First post! (Score:2)
I tried the Subversion equivalent but got trapped in the familiar hell of Cleanup and Unlock to fix a problem that came out of nowhere. Perhaps the commit got interrupted and Subversion still can't handle that rare edge case properly with transactions. In the end I had to go back and Checkout everything again.
Re: (Score:2)
All the closed source software for customers of mine (usually web apps and related services) was already on git when I took over the projects or has been migrated afterward (usually not my call). The only exception was a 1 GB svn repository of binary files that we don't really need to work much with and didn't make sense to convert. Anyway the two of us are too small a number to make a statistics. Just my two cents anecdote.
But in some environments git has become a de facto standard. Almost any Ruby gem is
Re: (Score:2)
Re: (Score:2)
git clone --depth 1
To add to this, last time I used SVN, it seemed to transfer each file individually which was really slow. Git compresses the files and then transfers everything
Re: (Score:2)
Sure, I've switched to git for my projects, but CVS is so easy to set up, centralized (it's a plus, when you need that), text files in repository and each file is versioned on it's own (it's a plus, when you need that). One great use I've found is put some software into git, manage patches with stgit, while having each individual patch in a CVS repository for patch history. I wouldn't change that for svn.
Re:Won't use SVN. (Score:5, Informative)
I don't understand however why CVS is so easily forgotten. I still use it on a daily basis.
It's forgotten only because SVN was intended to be, and is, "CVS done better". It was even created by CVS devs who wanted to start clean to overcome some of CVS's shortcomings, but intentionally and unabashedly looks, feels, and where possible, works like CVS. I've done both CVS (back in the day) and SVN repo setup, and they're both very simple. One reason I chose SVN for some in-house stuff is because the people who already knew CVS could pick it up in a heartbeat.
Re:Won't use SVN. (Score:5, Insightful)
All SCMs suck, some more than others. I liked CVS despite all its drawbacks. I can't help but dislike SVN despite all its upsides, notably its unbearably smug attitude, and especially its "documentation" drives me up the wall. Git, well, seems to be a reasonably solid bit of software and comes with somewhat usable manpages, despite its treacherous heritage. So we'll use that, reluctantly.
There are a few more alternatives I'd look at before looking at SVN again, in fact. And no apologies for not being sorry about it.
I'll bite. What's smug about svn? The developers make a version control system that they think is good, but they don't pretend it's The One True VCS. The users on forums, and Mercurial devs/users all likewise. By contrast Git fans, from Linus on down, act like it's the One True VCS and treat anyone who doesn't see the light as only worthy of contempt. I'm considering moving to Git or Mercurial, but I swear it'll be Mercurial just to get away from that friggin' attitude.
Documentation is also one of the strong points of SVN. The online book [red-bean.com] is fantastic.
Re: (Score:3)
Arch was first, then Mercurial and now Git. The main difference is that Git became much more popular thanks to the excellent Github, but for enterprise and large projects where a centralized repo works better, SVN or Perforce are still a
Re: (Score:2)
Treacherous heritage?
Re: (Score:2)
That being said, the only reason why we still continue to run with SVN, is that nobody is willing to make the effort to switch everything to Git.
and there are 5000 reasons not to use ClearCase (Score:2)
User License: USD $5,180.00