Re: Using SourceForge
- From: Andreas Stefik <stefika@xxxxxxxxx>
- To: programmingblind@xxxxxxxxxxxxx
- Date: Mon, 28 Jun 2010 20:21:18 -0500
Ken,
Yaa, I predominately agree. I think each has its place. Git and
Mercurial (which are very similar) are great for truly massive code
bases, where you have to do operations like you are mentioning
regularly. We really don't ever have to do that kind of stuff, so it's
less important. On the other hand, the power from that can lead to
problems too. For example, even a cursory look at GitHub reveals that
it's basically a complete mess. Even the most minor features are
branched off into a nether region and it becomes quite difficult at
times to figure out which version you really need. With subversion,
there's usually little doubt, as people don't branch as often, and
there's an official build number, even if on a branch build, which is
usable and easy to wrap your head around.
And then, on the other hand, I know folks out at Boeing that work on
code bases with millions of lines of code that still use CVS. I think
they're crazy, but they like it, and argue all day to defend it. Like
a lot of this stuff, there are some fine, objective arguments to be
made (e.g., algorithm efficiency, ease of use), but at the end of the
day, there's some personal preference that goes around as well.
Stefik
On Mon, Jun 28, 2010 at 7:59 PM, Ken Perry <whistler@xxxxxxxxxxxxx> wrote:
> Nod this can be as bad as an editor or screen reader war. My favorite is
> Git but understand I work on projects that are in the millions of lines of
> code (I.e. Linux kernels, and some other things ) The nice thing about git
> is you can totally copy your repository in one command. Try that in SVN .
> Then you can make one change to it that screws it all up and type one
> command and get everything back. This takes seconds not the long time it
> will take to take snap shots of SVN. There are ways of doing it in svn but
> it's not as fast or pretty or easy. Svn does have its good sides though its
> simple to use that's the big one you don't have to learn a crap load of
> commands like in git and it works easy in just about every Operating system.
> I would stay far far away from CVS though. The only two I suggest are SVN
> and Git. SVN if your project is under 100,000 lines or under 5 coders. Git
> if it is above that.
>
> ken
>
> -----Original Message-----
> From: programmingblind-bounce@xxxxxxxxxxxxx
> [mailto:programmingblind-bounce@xxxxxxxxxxxxx] On Behalf Of Andreas Stefik
> Sent: Monday, June 28, 2010 8:15 PM
> To: programmingblind@xxxxxxxxxxxxx
> Subject: Re: Using SourceForge
>
> Jay,
>
> If you are trying to upload source files, the typical way is to use
> version control. In our case, for example, we use subversion. If you
> pull up your project and click the develop tab (not the develop tab on
> the homepage), it will have a subversion address listed for the
> project.
>
> Here's ours, for example:
>
> https://sourceforge.net/projects/sodbeans/develop
>
> Using subversion, GIT, or CVS, is, in my opinion, the best way to put
> source files up, as it allows other folks to make changes at a whim
> (if you allow it by admin -> membership). And, just as neat,
> sourceforge keeps stats on everything related to it, it's
> automatically integrated into Trac, and it is just generally really
> easy for everyone, since it is standard. As for choosing a version
> platform, I know some folks that really love CVS, others that love
> subversion, and others still that think that anything but GIT is the
> devil incarnate. Personally, I prefer subversion, as it gives one,
> unified, build number, across the projects, and you never have to muck
> around with file versioning (CVS), or just as frustrating, separate
> personal repositories which never seem to sync up right (Git or
> Mercurial). I've used all of them, and prefer subversion, but keep in
> mind that that's just my personal opinion.
>
> Now, if you are wanting to upload a release ready file, however, it's
> a bit different. There's two ways to do this:
>
> 1. Project admin -> File Manager
>
> If you go to the file manager, you can release files and these are
> automatically sent through all the sourceforge mirrors. However, the
> interface is pretty clunky and works very poorly for large files (it
> crashes). In the Sodbeans project, our files are often 200-300
> megabytes, so we have to use system 2:
>
> 2. use rsync
>
> For large files, you need to use rsync from the command line. It's
> still pretty clunky, but this works really well. The command is
> something like the following:
>
> rsync -e ssh yourfile.exe
> username,projectname@xxxxxxxxxxxxxxxxxxx:/home/frs/project/pathtoyourproject
> /FolderYouWantItIn
>
> Generally speaking, if you are putting up largeish files, it would be
> wise to check Md5 checksums to be sure everything uploaded correctly.
> Every blue moon, one of the files we've uploaded has had a problem, so
> it's not a bad idea.
>
> Anyway, hope that helps. Personally, I'm excited to see what you folks
> have. I actually think we should consider collaborating on some of
> this code. Our team at Southern Illinois University already has
> working some code that integrates in a cross-platform, screen reader
> neutral way in Java, and it would be a shame if both our development
> teams ended up duplicating code unknowingly. Ours is somewhat NetBeans
> platform specific, as we are trying to make NetBeans more accessible,
> and there are enormous challenges in that as it is, but in practice
> we've spent a ton of time iterating through swing components, banging
> our head against the wall, and digging through debugger traces of
> swing code looking for how to "speak stuff" to the user.
>
> Cheers,
>
> Stefik
>
>
>
> On Mon, Jun 28, 2010 at 3:14 PM, Jay Macarty <jay.macarty2009@xxxxxxxxx>
> wrote:
>> Question for anyone who has used SourceForge to host a project. I can't
> seem
>> to determine the best way to upload files to the project. I was able to
>> upload a single file using scp but not sure how is the best mechanism for
> us
>> to collaborate on the java accessibility client so that people can
> download
>> the source, make contributions, and upload the changes.
>>
>> Also, just an FYI. I did recieve an answer back from the author of JNA
>> saying he would be more than happy for us to include JNA in our JAC
> project.
>>
>>
> __________
> View the list's information and change your settings at
> //www.freelists.org/list/programmingblind
>
> __________
> View the list's information and change your settings at
> //www.freelists.org/list/programmingblind
>
>
__________
View the list's information and change your settings at
//www.freelists.org/list/programmingblind
Other related posts:
