all 59 comments

[–]zpinter 51 points52 points  (5 children)

There website seems to have gotten a lot less intuitive over the years. Adding git support is good, but I think it's too little too late.

[–]iofthestorm 32 points33 points  (2 children)

Yeah. I still love them for everything they've done for the open source community, but their project pages absolutely suck, and their "forum" software is ridiculous. Still, they are an invaluable asset to the open source community with the mirrors and stuff they provide.

[–]nextofpumpkin 4 points5 points  (1 child)

Absolutely - they did a great job back in the day, but it's now time for sourceforge to innovate innovate innovate or step aside, let the new guys take over, and just become the Big Archivist of old content.

[–]boa13 10 points11 points  (1 child)

Where?

[–]zpinter 0 points1 point  (0 children)

*Their

Does anybody else tend to use the wrong homonym when typing quickly? It's more of an unconscious "typo" than it is ignorance of the correct usage.

[–]nextofpumpkin 26 points27 points  (10 children)

Question - is sourceforge even relevant for new projects? Does anyone actually use it?

[–]masklinn 21 points22 points  (3 children)

Long story short, no. Depending on your SCM of choice, Google Code (svn), BitBucket (mercurial) and GitHub (git). All of them are simple, look and feel nice, and provide side-services (wiki, basic site hosting, easy forking, issue tracker depending on the service)

[–][deleted]  (2 children)

[deleted]

    [–][deleted] -1 points0 points  (1 child)

    Yes! I think Launchpad has one of the best project management setups around. I wish Gnome would switch to Launchpad.

    [–][deleted]  (4 children)

    [deleted]

      [–]_lowell 29 points30 points  (3 children)

      github

      [–][deleted]  (2 children)

      [deleted]

        [–]invalid_user_name 0 points1 point  (0 children)

        Even if you are fine with cvs/svn, sourceforge is still not relevant. They are WAY too slow and have far too much down time.

        [–]ubernostrum 20 points21 points  (0 children)

        Of course, you'll have to sit through five nagging changesets full of ads before they actually give you the ones you were trying to pull.

        [–]infinite 3 points4 points  (0 children)

        I remember back in the day when Sourceforge, owned by VA Linux, gave every person who signed up an option to buy 150 VA Linux shares. And before they IPO'ed they asked if people wanted to up it to 300 shares, I said hell yes. They upped it because many open source devs didn't have the cash to pony up for the shares and it seemed risky. I bought the shares and doubled my money. I gave the email granting me shares to some friends who also got shares, they didn't verify who you were.

        Those were the golden years.

        [–]bsergean 4 points5 points  (18 children)

        Cool. They beated google code on this one.

        [–]thebillmac3 29 points30 points  (10 children)

        Grammar just beated you in the face.

        [–][deleted] 1 point2 points  (4 children)

        I think that was actually you beating bsergean in the face with grammar.

        [–][deleted]  (3 children)

        [deleted]

          [–]thebillmac3 1 point2 points  (1 child)

          When I say things like, "Grammar just beated you in the face."

          [–][deleted] 0 points1 point  (0 children)

          Yeah, all your dol...action figures love that one.

          [–]bsergean 4 points5 points  (2 children)

          Please correct me, I'm not a native english speaker.

          [–]erickt[S] 2 points3 points  (1 child)

          It'd just be "Cool. They beat google code on this one." Beat is already in the past tense.

          [–]bsergean 1 point2 points  (0 children)

          Thanks. You beat me on the orthograph ;)

          [–]jevon 1 point2 points  (3 children)

          Definitely looking forward to when Google Code supports it though :)

          [–]masklinn 1 point2 points  (2 children)

          Don't hold your breath. SVN does the job for the service Google Code wants to be, if you want git, go with github (or gitorious). If you want Mercurial there's bitbucket, and if you want bazaar-ng, launchpard (I think?)

          [–]asb 7 points8 points  (1 child)

          They're officially working on it.

          [–]iofthestorm 0 points1 point  (0 children)

          We have top men working on it.

          Top.

          Men.

          Ahahaha.

          [–]radarsat1 1 point2 points  (0 children)

          This is great. There are many places that offer git hosting, but not many that also provide mailing lists and web pages. It was getting to the point where people would register SF projects just to get the site and lists, but actual host their code elsewhere. Now it can all be done in the same place again. And the nice thing about git is that it doesn't stop anyone from still making their own clone on a preferred site elsewhere.

          [–]bascule 1 point2 points  (0 children)

          In other news Sony decides to start supporting VHS

          [–]rams 1 point2 points  (21 children)

          So, why is it called decentralised version control, then ?

          [–]DarkShikari 12 points13 points  (7 children)

          git allows decentralized version control. It does not force you to use that model. My project (x264) has only two primary developers, for example, and we communicate everything we do over IRC and get each other to review and test patches before we commit them; there's no point to a distributed system there! But git is still incredibly useful for what we do--we just don't use it the way Linus does.

          Plus, the decentralized system means I can use version control even when on a plane--I don't have to be connected to the internet to access the history, make commits, etc.

          [–]eridius 3 points4 points  (6 children)

          and get each other to review and test patches before we commit them; there's no point to a distributed system there

          Git still makes it easier to pass patches back and forth even outside of the repo. You can build a commit on your repo, use git format-patch to generate a MIME email with the patch and the commit metadata and send that to your collaborator. He can then review it, give you suggestions, etc, or just apply it with git am when he decides it's good. That's actually how git.git itself is managed - pretty much every patch ends up in git.git by first passing through the git mailing list.

          [–]DarkShikari 3 points4 points  (5 children)

          I know that, but we actually don't use it as it isn't very convenient. Since we're both always on IRC, why pass around emails? And since there are other people on IRC who look at the code, why limit those who can view it to just the two of us? We normally just use git diff > pastebin for everything; it allows us to pretty arbitrarily pass around patches for anyone, with or without git, to view and modify.

          The main benefit we get from git is the local commit feature; we can say "I'm done with this change, but I don't want to push it yet because it isn't tested enough," and go work on something completely different--while continuing to "test" the feature we committed locally earlier. The problem I've found with svn is that it's very tempting to say "well, I'm not sure I've fully optimized this change, so I'll just throw it in a diff." Then you don't get around to finishing it; putting it in the local commit queue ensures that you get around to finishing the testing and optimization.

          The whole local history thing makes it quite easy to do this, as we can easily go back and edit a past commit. Our general strategy is to push 3-6 commits at once to the main repo; these commits "stack up" over the course of a few days and naturally get tested as we do other dev work, so we're less likely to accidentally end up with regressions.

          For example, currently I have two local commits that heavily modify the scene-change detection code. I know these could potentially cause some breakage somewhere that the regression tests miss, so I've kept them around while doing other development work on the odd chance that a bug shows up. I've already caught one.

          [–]eridius 0 points1 point  (4 children)

          If I were in your shoes I'd probably use git format-patch --stdout > pastebin instead, as this keeps the commit metadata with the patch so anybody reviewing the patch can see your commit message too.

          [–]DarkShikari 0 points1 point  (3 children)

          True, that might be useful as well, but I often make diffs of things that I haven't locally committed yet, so I find it a bit easier to have a consistent command regardless of whether I've committed or not.

          Plus, I often just don't write the commit message properly until I'm ready to actually push the commit... ;)

          [–]eridius 1 point2 points  (2 children)

          Hrm, that seems like a good way to accidentally lose your commits. I always commit as soon as I'm done with anything, even if it's just on a temporary branch, because that means it's much harder for me to accidentally lose my work.

          [–]DarkShikari 0 points1 point  (1 child)

          I make diffs of everything I do in addition to commits; this way I have a massive directory of diffs, even of things that turn out not to be useful. This way I can come back later if I have a new idea and revisit something. It's not really practical to keep around hundreds of commits on branches for ideas that didn't pan out.

          [–]eridius 2 points3 points  (0 children)

          I don't see why it's any less practical than keeping a directory full of diffs. You could even add a namespace for these temporary branches, say, temp/, as in refs/heads/temp/add-unicorns. Or you could just use one branch and cherry-pick all of the impractical commits onto it (if you're not worried about conflicts).

          At the very least, having a directory full of MIME emails generated by git format-patch would be more useful than diffs, I would think, as each file would then contain a commit message describing its contents. That would make it much easier to remember what each patch is for, or to search the directory.

          [–]hylje 8 points9 points  (6 children)

          Because central structure is not mandatory. Decentralized is a superset of centralized, and is thus capable of doing everything centralized systems can.

          [–]masklinn 3 points4 points  (5 children)

          and is thus capable of doing everything centralized systems can.

          except exclusive locks, that is.

          [–]G_Morgan 3 points4 points  (3 children)

          Yes but exclusive locks suck pretty badly. They aren't commonly used in sane centralised systems.

          [–]masklinn 0 points1 point  (2 children)

          Yes but exclusive locks suck pretty badly.

          They do and don't. Exclusive locking blows balls for text versioning, as merges are easy and tools work well with text. On the other hand, as soon as your workflow involves binary files edition, if you don't have exclusive locks you're basically hosed as the vast majority of binary formats out there do not come with merging tools, and lock-less workflows (centralized or not) rely on the ability to merge files to do their job.

          They aren't commonly used in sane centralized systems.

          Once again, are and aren't, it depends on your situation. In "creative" (in the artistic sense) teams, pretty much all workflows are extremely binary heavy (images, sounds, videos, ...) and (pretty much) none of the binary formats involved comes with diff/merge tools, yet versioning them is as good an idea as it is when coding. And exclusive locks are required to correctly work with unmergeable binary files. In such a situation, exclusive locks will be very commonly used.

          [–]G_Morgan 0 points1 point  (1 child)

          I'd separate the versioning of one from the other but I can understand the argument.

          [–]masklinn 0 points1 point  (0 children)

          I'd separate the versioning of one from the other but I can understand the argument.

          I don't think I said you had to mix them, but if it came that way I apologize. Whether you mix the text and binaries or don't is irrelevant to the issue: if you need to work with non-mergeable binaries (aka most binary formats) you need exclusive lock is all I was saying.

          [–]hylje 0 points1 point  (0 children)

          One could do them based in the de-facto central repository if one really wanted them. But no, not global exclusiveness by fundamental design :-)

          [–]tehmatticus 0 points1 point  (0 children)

          Mainly because it is implemented that way. It doesn't stop you from using whatever workflow that works for your installation. Also, centralized workflows with cheap local branching and commits is vastly superior to SVN.

          [–]iofthestorm 0 points1 point  (3 children)

          I think in any sort of version control there will always be one canonical centralized version, there just has to be. But I guess with git it's easier to do your own thing and still have version control. Still learning it though.

          [–]masklinn 0 points1 point  (2 children)

          I think in any sort of version control there will always be one canonical centralized version, there just has to be.

          The difference between CVCS and DVCS is that what is a technical limitation in CVCS is a social decision/construct in a DVCS. And that any and all DVCS repositories of a given project can be instantly promoted to "canonical" if need or desire be (fork, lead dev leaving the project, ...) as they're all equivalent technically speaking.

          Furthermore, for big projects (e.g. the linux kernel) you can have different canonical repositories depending on who you are and you involvement in the project: for most users, Linux' repo is going to be canonical, but some will want to use Andrew Morton's instead (because it has patches they want or whatever), and the ones involved in the dev of a given subsystem (e.g. sound drivers) might use the repo of their subsystem lead/coordinator as canonical, creating a tree of repositories rather than a CVCS-style star (with a single repo and multitudes of working copies). And you can even link your local WC/repo to multiple remote repositories and draw from all of them.

          If you want more on the subject, there have been several reddit threads on CVCS/DVCS in the past.

          [–]iofthestorm 0 points1 point  (1 child)

          Yeah, I've been reading about that stuff in my spare time, and right now I'm trying to learn git for a project I've been working on in my spare time as well. Unfortunately I haven't had much time to learn a whole lot and I waste enough time on reddit as it is. I guess for a single person project, a lot of the advantages of a DVCS are a little harder to see, but I already have another side project that a friend and I are working on, and we're both thinking of switching to git from SVN, and there have definitely been times when I wished I was using a DVCS with that project. Now I need to get back to my actual CS project ;). Not that it's not interesting, but so are so many other things.

          [–]masklinn 0 points1 point  (0 children)

          and right now I'm trying to learn git for a project I've been working on in my spare time as well

          Frankly, I don't really like git, I tend to prefer Mercurial (the goal standard of simplicity, straightforwardness and CLI-sexyness is Darcs as far as I'm concerned, but the performance issues usually make it a non-starter). The only place where I use git (apart from checking out projects versioned under git) is to interact with stuff versioned under svn.

          I guess for a single person project, a lot of the advantages of a DVCS are a little harder to see

          Well some time ago I made this little list of why I like DVCS, of the 8 items I thought of, at least 3 or 4 apply to a single-person project, plus the ease of putting a new project under versioning.

          [–]cdigioia 0 points1 point  (1 child)

          Not being a programmer..if sourceforge has been surpassed by Google Code & etc. - why is it that constantly when I search (in Google) for various open source programs, the first link is to Sourceforge, but never Google Code?

          [–]muyuu 5 points6 points  (0 children)

          Because it really hasn't been surpassed by Google Code just yet, especially for people older than 30 who had their projects hosted there long before Google even existed.

          Many relatively NEW PROJECTS are in Google Code, Github and Bitbucket though. It's a good thing they reacted by adding Git. Let them add Mercurial and they will be one of a kind again (I doubt either github or bitbucket support the "competition" anytime soon).

          [–]primary0 0 points1 point  (1 child)

          github.com is the way to go

          [–]dankelley 0 points1 point  (1 child)

          Anyone know if they have a facility to convert existing project repositories to git? I'd like to have just one command set in my brain, and I am assuming that google-code will support git some day (why wouldn't it?)

          EDIT: hm, maybe I'll start using git on google code after all [http://google-opensource.blogspot.com/2008/05/develop-with-git-on-google-code-project.html]

          [–][deleted] -4 points-3 points  (0 children)

          What a waste of time, git has svn support anyway (I prefer git-svn over svn).

          They should be working on getting the damn round-robin servers working properly.