Ok, after a lot of hassling from you lot, asking for CVS access to Juce, I’ve finally got round to setting it up on SourceForge. The URL is:
I’m still getting the hang of sourceforge, which seems enormously fiddly to use, but will hopefully start shifting all the downloads over to it as soon as I can figure out how it works…
oh, don’t use CVS, use Subversion instead, is miles better !!!
gr8 news jules !!!
I have to agree about CVS. Drop it like a hot potato!
Otherwise, this is a very nice development. 
I’ve always used CVS, never tried subversion - how would it make my day-to-day life better?
in a lot of ways. subversion mainly is more consistent than cvs, it deals better with binary files, it record directory changes and file move / deletion (so you can go back to a perfectly consistent file tree structure), it doesn’t need to autenthicate to check out or do annoying stuff like the useless “login” command in CVS. also, doing merges branches is somehow simpler.
i have used both for years and i feel miles more confortable with svn.
Understood. Having had a go of both, I’m moving it to subversion now…
There is a very useful utility for windows : TortoiseSVN
All you have to do, is, before working on Juce, right click on your juce folder => Update
After working on Juce, right-click on the juce folder => Commit…
It’s not harder than that.
Clearly, it’s way way easier than remembering all those special commands, even easier than using a zip file like previously.
Jules, do you have bandwith issues with rawmaterialsoftware.com ?
Yes, I’ve discovered TortoiseSVN now, it’s a neat bit of software.
No, not at the moment - why do you ask?
It’s the “shifting” part of your sentence. Sourceforge is great, but is very volatile (they never have more than 60% uptime, at least in France I guess). I hope you won’t remove your code/help from your site.
Really? It’s always seemed pretty solid for me.
My main reason for putting it there is for the source-control, and also to make it easier for people to discover. I’ll probably keep most of the stuff on my website, with links to/from sourceforge. Will just see how it goes, really.
Hi,
I just checkout’d the svn trunk and it looks like you did a wrong operation with tortoise svn. the files in these directories :
build\macosx
build\linux
build\linux\platform_specific_code
have a “.tortoise.removed” suffix.
unrelated question :
Do you plan to commit frequently your changes or only when you consider it should be a new version ?
Oh, that’s annoying, I’ll get it sorted out…
I’m planning on checking stuff in regularly, so there’ll always be an unstable tip build there if anyone wants it.
just some little tips for you julian…
/
|--->/trunk
|---->extras
|---->src
|---->....
|--->/tags
|---->juce_1.42
|---->juce_1.41
|--->/branches
|---->juce_graphics_openglthis way you could have parallel revisions running, without dirtying the main development trunk.
this is very useful when u need to do a release, you will “tag” the head revision in the trunk, with a specific directory name in the “tags” directory, so we can checkout a particular version and do diff over that easily.
also the branches directory will ease create parallel version of the main trunk when u got to experiment with something to merge it back in the trunk when it’s going to work.
ah doing tagging and branching and merging is easily doable with tortoise (right click “tag”).
it’s not mandatory, but it will help you (and help us fellows) in the long run …
cheers!
yeess… I sort of agree, but that’s all a bit more complicated than the way I want to run this. Certainly there will never be any branches, I’ve always hated working on branched projects, it just causes chaos. And my changes don’t always tend to come along in easily commented chunks, so unlikely that I’ll be too disciplined about that!
Adding tagged builds is a good idea, though, I was going to do that as soon as I’d got the hang of it…
yeah i understood your points.
anyway you checked in juce_TaskbarIconComponent.cpp.bak and juce_TaskbarIconComponent.h.bak backup files in the component/special folder. probably shouldn’t be there
ah - yes, those pesky .bak files… Ta!
yap… i always stick a monthly cron job that spots and exterminates those (especially when they got tildas and date in the name, which i hate)
I’ve got a batch file for cleaning them up, but there’s always one or two that escape…
That is one of the beauties of subversion, each branch/tag is an O(1) operation since it just marks which revision of the repository is the branch (or tag) 
In RCS (or CVS), each file needs to be gone through…
