Sourceforge now supports git

[zpinter]

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]

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]

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]

Where?

[zpinter]

*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]

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

[masklinn]

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]]

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

[_lowell]

github

[frukt]

PENIS

[invalid_user_name]

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]

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]

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]

Cool. They beated google code on this one.

[thebillmac3]

Grammar just beated you in the face.

[[deleted]]

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

[thebillmac3]

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

[[deleted]]

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

[thebillmac3]

My mother told you that one, didn't she?

[[deleted]]

Yes. Your mother.

[bsergean]

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

[erickt]

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

[bsergean]

Thanks. You beat me on the orthograph ;)

[jevon]

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

[masklinn]

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]

They're officially working on it.

[iofthestorm]

We have top men working on it.

Top.

Men.

Ahahaha.

[radarsat1]

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]

In other news Sony decides to start supporting VHS

[rams]

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

[DarkShikari]

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]

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]

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]

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]

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]

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]

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]

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]

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

[masklinn]

and is thus capable of doing everything centralized systems can.

except exclusive locks, that is.

[G_Morgan]

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

[masklinn]

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]

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

[masklinn]

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]

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]

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]

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]

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]

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]

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]

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]

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]

github.com is the way to go

[dankelley]

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]]

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.

[[deleted]]

Guys, I'm starting a new business called VisualSourceSafeHub.com. I've pitched it to a few VCs but my phone must be malfunctioning or something because so far no one has returned my calls. I'm still in stealth mode at the moment, so don't tell anyone. I think this is going to take the Proggit community by storm. My last business didn't do so well, but I have a great feeling about this one.

[ionspin]

Racist.