| |||||||||||||
It's not dead yetIt's not dead yetPosted Jan 15, 2009 9:41 UTC (Thu) by niner (subscriber, #26151)In reply to: GNOME considers DVCS choices by rrdharan Parent article: GNOME considers DVCS choices
Tough DVCS are very much on the rise in the FOSS community, there are places where
a centralized VCS is still the preferred way to go, which will likely stay that way. For example for the in-house development stuff of the company I work for and for sure many others. We do want to have everything centrally on our backed-up server and it's very nice to have subversion available for that.
(Log in to post comments)
It's not dead yet Posted Jan 15, 2009 9:49 UTC (Thu) by johill (subscriber, #25196) [Link]
It's not that a DVCS doesn't allow you to have that kind of workflow, if you look at the kernel you'll notice that it almost does have that workflow with many many maintainer trees being hosted on git.kernel.org. But I do agree that it's easier to enforce with svn, since it simply doesn't allow locally committing.
It's not dead yet Posted Jan 15, 2009 13:50 UTC (Thu) by kpfleming (subscriber, #23250) [Link]
Actually. plenty of developers on Subversion-hosted projects use svk locally to do their work, and then 'push' the results upstream. This is harder to setup and use than if the project used git. In addition, developers are now starting to use git-svn to do the same thing, so the days of the 'master Subversion repo' being the place where everything lives because the tool doesn't allow for any other mode of operation are already gone.
In the future, if the project needs a central 'blessed' repository and wants all work to be done in the open, those needs will have to be met through policy statements and enforcement, because the VCS isn't going to do it.
We have shared git repositories Posted Jan 15, 2009 15:41 UTC (Thu) by emk (guest, #1128) [Link]
At work, we use shared git repositories on a central server. Everybody working on a given project has "push privileges", and they're strongly encouraged to push to master at least once per day.
This has a number of advantages:
1) Git is much easier to back up than Subversion. Correctly backing up Subversion requires an expensive hotcopy step (at least for our ~30GB repository). Git repositories can be backed up either by mirroring, or by straightforward disk backups, thanks to the reflog. (There's a way to recover a Subversion repository backed up in the middle of an operation, but it's messy.)
2) Git+SSH places a lower load on the server than SVN+SSH. At least for big repositories, Git's data structures take far less disk IO to initialize on first launch than Subversion's. This matters to people logging in via SSH.
From a sysadmin's perspective, git is well-behaved. And it supports a very wide variety of workflows, so not every project needs to work like the Linux kernel.
We have shared git repositories Posted Jan 15, 2009 18:47 UTC (Thu) by drag (subscriber, #31333) [Link]
Ya.. Were I work we have a central Git server that is 'official' then each user hacks on their own little world.
Then when you want to submit your work you clean it up, make sure all the important revisions you've worked on are represented and push it back up to the central git server. That way you get the benefits of showing all the major stages you've gone through, and get it represented in the history on the main git server, in your own work while avoiding forcing users through the dozens of commits a hour you do while hacking away.
It's very nice to do a commit every time you close out a file or make a risky edit to something. The more you use it the more useful it gets.
|
|||||||||||||