SourceForge seems to have a massive outage. Apparently the storage for their virtual servers got corrupted. I noticed, because an update to the GEXperts source code failed.
SourceForge seems to have a massive outage. Apparently the storage for their virtual servers got corrupted. I noticed, because an update to the GEXperts source code failed.
Don't expect your code repositories to be up again soon:
We’re holding SCM service restoration for last, and will be prioritizing Git service to be first within that process based on its fast verification path. Holding SCM restoration for last allows us to take a cautious approach and to free our staff to interact with developers if any concerns exist when the service is re-enabled
http://sourceforge.net/blog/sourceforge-infrastructure-and-service-restoration/
Don't expect your code repositories to be up again soon:
We’re holding SCM service restoration for last, and will be prioritizing Git service to be first within that process based on its fast verification path. Holding SCM restoration for last allows us to take a cautious approach and to free our staff to interact with developers if any concerns exist when the service is re-enabled
http://sourceforge.net/blog/sourceforge-infrastructure-and-service-restoration/
One more reason (if you needed another after the malware scandals, and project takeovers) to migrate projects from SourceForge to Github or Bitbucket.
ReplyDeleteInterestingly uBlock blocks sourceforge - ie including the above link - as a potentially dangerous site.
David Millington why would Github or Bitbucket be less likely to have similar problems?
ReplyDeleteThomas Mueller Well if you migrate to git or mercurial in the process then such outages matter way less. Everyone in the team can still work just fine, and it is trivial to set up a temp repo if you really want a central repo.
ReplyDeleteThomas Mueller They're not, but SF having a problem like this is just icing on the cake of their major ethical problems and criticism over the past few months. Those alone have caused lots of people to migrate - an outage is just yet another reason.
ReplyDeleteSince GExperts, the only major project on sourceforge to which I contribute, is not my project, that's not my decision to make. I happen to like svn better than those distributed SCMs. Apart from that I'm too lazy. I just moved all my small personal projects from berlios to sourceforge a few months (at least it feels like months, it has probably been several years since) ago, I'm not keen to do that again.
ReplyDeleteFWIW: I like SVN as much as the next guy, we're still using SVN at the place I'm currently at, but it's also clear that anything SVN can do, {git|bazaar|hg|fossil} can do just as well or better, plus they can do several things SVN can not. It's only a matter of time before we migrate. It used to be a bit of a challenge to migrate from SVN but mostly this has also become less of a valid excuse than it used to be, though in individual situations will obviously still vary. (For some of my own stuff I also still use bzr, at some point I'll probably look to convert/migrate this to git as well.)
ReplyDeleteWalter Prins The feature I miss most with any other SCM is externals. I want to keep my libraries in their own repository (or rather they are grouped into two repositories separate from the programs). But still, checking out a program's source should result in a source tree containing everything necessary to build it. I don't want to share the library sources between the programs, but I want to share the repositories they are in. Every time I look for a similar solution in any other SCM I draw a blank or find something half working which of course breaks whenever I need it the most. And please nobody tell me about the svn support of git and hg: They just don't work well and guess what they don't support? Exernals (at least that was the case last time I looked). Of course, now everybody and his cousin will tell me that I just have to adapt to the way the other SCMs work. No, I don't have to. There is one SCM that works exactly the way I like it: svn.
ReplyDeleteThomas Mueller Fair enough. That's one thing from SVN we don't actually use -- we keep all third party/external dependencies in their own repo and these are manually upgraded/updated/tested in a controlled manner and then committed once we're happy to do so, in conjunction with any changes required to keep things working in the main code repo. The CI server (Jenkins in our case) automatically always monitors and checks out any changes both to the main repo as well as the third party/externals repo. Anyway, peace. Don't want to be polemical. :)
ReplyDeleteJust to ask/add -- does your comment imply that you've looked at git submodules, which, so I read, is somewhat similar to svn-externals, and run into issues with it? (Genuinely curious given our plans to eventually migrate and although we don't currently use svn-externals I might have a look at git-submodules to, as you say, get to a place where 1 checkout gives you everything you need to build.)
ReplyDeleteWalter Prins I don't know how svn externals work, but git submodules are a bit awkward as you have to constantly keep them in mind when working on your repos. Mostly a UI thing though from what I can gather. After all, git's UI is not very user friendly.
ReplyDeleteWalter Prins I don't remember the specifics, but I looked into git submodules and they weren't the solution. Hg also has a similar concept, don't remember what it was called.
ReplyDeleteThomas Mueller Hg has SubRepos or GuestRepos - depending on your use case.
ReplyDeleteThomas Mueller Git submodules do exactly what you described. And migrating an svn repo to git is just a matter of one command call. More difficult though is changing your thinking from svn to git (or any other DVCS) but it's worth it.
ReplyDeleteStefan Glienke last time I tried it, submodules didn't work the way I expected them to. That was a while ago, maybe something has changed or maybe I didn't understand them. I find git more difficult to understand than svn or hg.
ReplyDeleteThomas Mueller I agree about the git UI. I'm hoping some team will fork git and rewrite all the tools, keeping the git core.
ReplyDeleteSourceTree (1.5.2 - download link http://downloads.atlassian.com/software/sourcetree/windows/SourceTreeSetup_1.5.2.exe - don't update because 1.6 is crap) - best Git UI you can get (also works with Hg)
ReplyDeleteStefan Glienke The problem is that all the tools I've tried "leak" the git tools UI into their UI. I guess to make it consistent with how the tools work.
ReplyDeleteI find the way the git tools work to be quite unintuitive, especially compared to say mercurial. For example, "git reset --soft HEAD~1" instead of "hg rollback".
That's why I wish for someone to fork git and rewrite the tools.
Asbjørn Heid Whats wrong with clicking on a commit, right click and select "reset to this commit" and then selecting if you want to keep the changes or do a hard reset?
ReplyDeleteStefan Glienke Reset what? What am I resetting? What's "hard" about a hard reset? I just want to roll back my last commit...
ReplyDeleteI feel with hg it's much more clear what exactly you're doing. With git you really need to know the internals to get anywhere, and thus a lot more to remember and easier to forget. With hg it took me a week or so and after that I hit google max once a month.
I've used git for a half a year now (on my hobby projects), primarily using SourceTree, and besides committing and pushing it feels like I have to hit google all the time. If only to make sure I don't screw up and lose data.
Asbjørn Heid I've heard that argument often enough - and after initially being a hg fanboy when we were evaluating hg or git to use at work I started liking git. People always tell me that you can screw up things but that is mostly the fear of unknown. I've only seen someone screw up a branch by false merging once and I would say that even in hg he would have made that mistake but reverting to a prior commit and doing it right solved the problem.
ReplyDeleteI cannot say if mercurial projects look better but many people just don't know how to use git properly (I mostly notice when I see more merge and revert commits in a history than actual commits).
And after all a dvcs is not a childrens tool so personally I can handle a bit of complexity.
Stefan Glienke Well when I first started with git (some years ago) I did manage to lose data. I can't recall what happened, but it was related to reverting a commit. Though at that time I didn't have SourceTree (it was on Linux anyway).
ReplyDeleteAnyway, personally I want my vcs to "just work", and not be something I have to think a lot about. SourceTree helps a lot, but it still exposes me to git internals that I frankly don't think I need to know.
Asbjørn Heid Well, then use hg and be happy. :) For me git just works. Anyway I think this is going into a "personal preference" discussion that has no winner.
ReplyDeleteStefan Glienke Well hg has issues too. It works great for some projects, but not for others.
ReplyDeleteLike I said, I'd prefer it if someone rewrote the git tools, keeping the git core. SourceTree is good but not radical enough (I get that they're not trying to be radical).
I find Mercurial a lot easier to use. Git is the perfect example of a tool written by programmers - very powerful, impossible to use. I've spent a good part of my professional life taking software designed by very intelligent and very out of touch programmers and making it useable by other people (including programmers who value usability, and I'd put myself in that category) and it's sad / frustrating to see something like Git exist in 2015. We as a profession should know better by now.
ReplyDeleteI still use it, but... :/
I use git almost entirely from a command line and I find it incredibly powerful and liberating. I can't imagine life without it now. I didn't find it that hard to Grok personally but I know a lot of my coworkers struggle with it's distributed nature and the various states files can be in.
ReplyDeleteMike Margerum I could probably grok it. But I don't want to have to put an effort into, for the same reason I don't miss putting an effort into freeing enough of my 640k memory to play a game.
ReplyDeleteAsbjørn Heid understood. But, the concepts you have to grok aren't superfluous or unnecessarily complicated. It's just the lifecycle of files in a Git repo and any sane distributed version control is going to have similar concepts. I think it's brilliant and a huge upgrade to any centralized VCS. I've used CVS, subversion, and source safe. Git is superior to them all. I can't speak for HG because i honestly don't know much about it.
ReplyDeleteMike Margerum I'm with Asbjørn Heid here: If it's difficult to understand one of your coworkers or even you yourself will botch it and you will be worse off than without an SCM. I know people who struggle to use svn correctly even with the help of TortoiseSVN. I don't want to imagine what kind of abuse they could make of git.
ReplyDelete"Of course I committed my changes to the repository. I even wrote a very good comment. It must be there. I can see it in the history." Then you investigate and find they either committed only locally or pushed it to the wrong repository, e.g. one that was meant for training only.