4 ms·

I have a source code repository for the code I write on my computer to track changes, and then I upload tar.xz's of the project for each "release". I can't see

by un_ 11y ago

I have a source code repository for the code I write on my computer to track changes, and then I upload tar.xz's of the project for each "release". I can't see much benefit in opening a source code repository; if someone finds a bug, he can e-mail me a patch or even notify me about it. Having a repository where many people can come and open issues puts a burden on my shoulders - I'll look at the page and see that I need to fix <some number> of issues, otherwise I'll look bad, or people will stop using my code. Releasing my code in releases (so that everyone is on one release, or not on any release at all) means that I don't have to deal with people who've cloned the code half-way through the implementation of something large and complained that it won't run, or that it's full of bugs. Releasing releases has been a solid model for me, especially as I work alone, or with a maximum of two or three other people at once. If I was going to use a public repository, I think I'd end up using CVS.

shiro 11y ago
If it's a personal project, it's largely a matter of taste, I think. I did tarball-upload style myself before. I just like to comment that having public repo doesn't necessarily mean you suddenly have to deal with issues piled up by others, although in recent trend repo providers do encourage that kind of open communication (On github, I can turn off issue tracker but I don't know how to turn off pull requests). Even using private repo, you still get bug reports, feature requests and patches via email, or (worse) stumble upon a blog or tweet complaining something isn't working for somebody. The reason I moved to public repo for my projects was that I got tired of dealing with patches manually - sometimes people sent patches against the release which was already fixed in my repo or had conflict with HEAD; sometimes I couldn't reproduce the problem so I had to send provisional patches to the user reported a bug to check out if that would address the issue. With public repo, I could just say "give me a patch against HEAD" or "I push a potential fix on a branch so check it out". It's so much easier. But again, this all depends on what kind of feedback you're getting, or how often your releases are, etc.
kazinator 11y ago
> if someone finds a bug, he can e-mail me a patch or even notify me about it. A source code repository can help someone find a bug more easily, and "preprocess" the bug report with more info for you, like "Hey, you broke such back on December 3, 2014---all you have to do is revert that commit's change to foo.c, and keep the other changes." Users can run "blame" to find out which commit touched what line of any file. Of course, you can debug a flat tarball, but it's sometimes better with the history. Particularly in cases when something previously used to work (users are running into a regression). If all they have is the previous release tarball and the new one, there are too many changes which could be responsible for the breakage. > then I upload tar.xz's of the project for each "release". All I do is push the release's git tag to my public repo, and the CGIT web front end automatically creates .tar.gz, .tar.bz2 and .zip download links for that tag: $ git tag frumly-widgets-2.3 $ git push --tags Done! Users can now download frumly-widgets-2.3.tar.gz straight out of the web front end. > If I was going to use a public repository, I think I'd end up using CVS. Thus, exposing a public version control repo is too uncool for old school, but if you use some unfashionably crappy old version control system, then it's acceptable.
greghendershott 11y ago
You politely and clearly explained why you're unconvinced a repo would benefit you. You got a couple replies pointing out some advantages, which maybe you hadn't considered or at least some other people might not have known about. Result? Nice discussion. Opportunity for folks to learn something new. And yet, your comment is gray from down votes. Since it would look bad for you to complain about that, I will: That sucks.

by un_ 11y ago

shiro 11y ago

If it's a personal project, it's largely a matter of taste, I think. I did tarball-upload style myself before. I just like to comment that having public repo doesn't necessarily mean you suddenly have to deal with issues piled up by others, although in recent trend repo providers do encourage that kind of open communication (On github, I can turn off issue tracker but I don't know how to turn off pull requests). Even using private repo, you still get bug reports, feature requests and patches via email, or (worse) stumble upon a blog or tweet complaining something isn't working for somebody. The reason I moved to public repo for my projects was that I got tired of dealing with patches manually - sometimes people sent patches against the release which was already fixed in my repo or had conflict with HEAD; sometimes I couldn't reproduce the problem so I had to send provisional patches to the user reported a bug to check out if that would address the issue. With public repo, I could just say "give me a patch against HEAD" or "I push a potential fix on a branch so check it out". It's so much easier. But again, this all depends on what kind of feedback you're getting, or how often your releases are, etc.

kazinator 11y ago

> if someone finds a bug, he can e-mail me a patch or even notify me about it. A source code repository can help someone find a bug more easily, and "preprocess" the bug report with more info for you, like "Hey, you broke such back on December 3, 2014---all you have to do is revert that commit's change to foo.c, and keep the other changes." Users can run "blame" to find out which commit touched what line of any file. Of course, you can debug a flat tarball, but it's sometimes better with the history. Particularly in cases when something previously used to work (users are running into a regression). If all they have is the previous release tarball and the new one, there are too many changes which could be responsible for the breakage. > then I upload tar.xz's of the project for each "release". All I do is push the release's git tag to my public repo, and the CGIT web front end automatically creates .tar.gz, .tar.bz2 and .zip download links for that tag: $ git tag frumly-widgets-2.3 $ git push --tags Done! Users can now download frumly-widgets-2.3.tar.gz straight out of the web front end. > If I was going to use a public repository, I think I'd end up using CVS. Thus, exposing a public version control repo is too uncool for old school, but if you use some unfashionably crappy old version control system, then it's acceptable.

greghendershott 11y ago

You politely and clearly explained why you're unconvinced a repo would benefit you. You got a couple replies pointing out some advantages, which maybe you hadn't considered or at least some other people might not have known about. Result? Nice discussion. Opportunity for folks to learn something new. And yet, your comment is gray from down votes. Since it would look bad for you to complain about that, I will: That sucks.