[wolf]

you guys should really consider moving to SVN instead of CVS, it's way better.

If we did, would you join the SCP?

It would be much easier to join, if one wouldn't have to fight with the CVS mess. And to have dev mailing list that everyone could read. And to have commit list available to anyone...

Currently there's no way for anyone that isn't a dev to follow fs2open progress. And if I can't see if the project is alive, why should I bother to join it?

[Shade]

What's messy about CVS? As a complete newcomer with no experience at all, it would take all of 5 minutes to check out the code using the walkthrough in the wiki (now with images too thanks to jr2's work). And after that, keeping your code current is as simple as right clicking on the folder with the code and selecting CVS Update.

[karajorma]

Yep. TortoiseCVS is very easy to use. In fact although I don't doubt that SVN has advantages over it I doubt that anyone who can't use CVS would be able to use SVN either.

The other points are quite valid though.

[wolf]

What's messy about CVS? As a complete newcomer with no experience at all, it would take all of 5 minutes to check out the code using the walkthrough in the wiki (now with images too thanks to jr2's work).

As a developer you want to do much more with your revision control system than just a checkout.

And after that, keeping your code current is as simple as right clicking on the folder with the code and selecting CVS Update.

Great. Now show me, how do I check out the very code that was used to make given build. With svn if I know that the build was made from revision 573, then I just need to checkout revision 573. With cvs the best I can do is checking out repository using some obscure time stamp, which is imprecise at most.

Next thing, show me how I can see what changed between one revision and another. In svn I can do svn log -r 532:516 and have overview of all changes. In cvs I have to check every single file (726 source files on HEAD currently) for changes, again, comparing timestamps, as the logs are per-file, not per-commit. In many cases I will be reading the same commit message in different files.

Branching. Show me how can I see all the branches in code. In svn I can just do svn ls /path/to/repository/branches and here they are. In cvs I have to check all the files in repository, because some files may have been added after the branch, for example 3.6.10, so if I check what branches these new files have I couldn't notice that there is a 3.6.10 branch. Someone might have been smart and do a branch only on a small subset of files to, for example, check the new sound code. If I did not explicitly check these files for branches, I would never know there was a branch.

Client-side directory deletion also is very simple in cvs.

Sure, cvs is great for cases where you have set of independent files. All these files have their own revisions, could have their own branches, etc. But cvs really sucks when the files in repository are all interconnected and you need to think of them as a whole.

[Turey]

As a developer you want to do much more with your revision control system than just a checkout.

Speaking as someone who IS an SCP developer, I've never seen a need for anything more complicated than checkout, commit, and simple commit logs. Maybe if we were merging branches on a regular basis, we might need some more versioning tools, but we don't do that more than once or twice a year.

Branching. Show me how can I see all the branches in code. In svn I can just do svn ls /path/to/repository/branches and here they are. In cvs I have to check all the files in repository, because some files may have been added after the branch, for example 3.6.10, so if I check what branches these new files have I couldn't notice that there is a 3.6.10 branch. Someone might have been smart and do a branch only on a small subset of files to, for example, check the new sound code. If I did not explicitly check these files for branches, I would never know there was a branch.

The SCP greatly discourages branching (We try to keep it to two branches at all times, HEAD and stable[currently 3.6.9 branch]), and I've NEVER heard of anyone doing a partial branch on any project.

[taylor]

I don't really want to get into this CVS vs. SVN thing, but I do agree with wolf on this.  The problem is that CVS isn't being used properly as it is, and I see no hope of SVN being used properly either, if such a switch were made.  It's been pretty obvious that SCP devs (over the history of the project) can't really handle branching worth a crap even though it could help not only speed up development, but allow for much more stable code as well.  SVN has many advantages, but they are only of benefit if they are used responsibly.  CVS is abused so badly right now that SVN would surely get the same treatment.


@wolf:  I have wanted a ML for basic dev discussion, but that never seems to fly with anyone else (except perhaps Goober5000, but we just email each other and a ML isn't needed for that ).  The commit ML has never been private until recently though.  When warpcore discontinued the ML, we had to move it to another host.  The host in question is somewhat bandwidth limited though, which is why the list subscriptions are a bit more controlled.  You have certainly contributed enough to warrant access to the list however, so PM me if you are interested and I'll get you the info you'll need to subscribe.

[Goober5000]

I do agree with taylor and wolf here.  The SCP, from the beginning, seems to have suffered from one major inherent flaw, and that is that it's composed of high school and college students who have little to no practical work experience.  That means that everyone treats the codebase as his own sandbox, and "everything is fine" as long as the sandboxes don't step on each other.

So we end up with people who have no formal training with CVS/SVN, very little training on ground rules, and only the most grudging acceptance of code freezes and bug hunting drives.  If we had more coders with actual work ethic mindsets, things would be better -- certainly more organized and less chaotic.

Now I am not opposed to a complete overhaul of the SCP with the intent of switching it over to a more professional project team, but we would have to think carefully about how we want to do it.  (On the other hand, most of the developers are so inactive these days that the disruption might be much less than would appear at first glance.)

[Swifty]

How would one join the SCP, BTW?

[Inquisitor]

We've talked about this at length internally. I am (as I believe are taylor and goob) open to suggestions, and would welcome experienced hands.

We actually also talked about a SVN conversion, since we are a little concerned about the long term stability of the current CVS host. Someone just has to have the time to do it. I agree with taylor, though, we don't use CVS right as it is, if we tagged builds and branched appropriately, you could just download revision 573, etc with the current system, and that has been a long running problem, The folks who have tried have not been particularly successful, and there is a far amount of it for just one guy to make it all work right if that guy has anything else going on in his life

The SCP greatly discourages branching (We try to keep it to two branches at all times, HEAD and stable[currently 3.6.9 branch]), and I've NEVER heard of anyone doing a partial branch on any project.

Context is important here, we discourage it because it tends to get out of control, branching needs a little care and feeding in CVS, and some dedicated developer time to making sure its kept up to date. We've tried it a couple times, and ended up with messes each time. So its sorta a ban thats fed on itself, not for any good reason other than a couple of largish mistakes.

All of which puts us where we are, organizationally. We can attack it one guy at a time, or we can make sweeping, wholesale changes. The former frustrates the people who are waiting for us to do it right because it takes too long, and the latter frustrates the people who have been around a while who think that change is too painful. In an all volunteer org, incentives for change are hard to come by.

Currently there's no way for anyone that isn't a dev to follow fs2open progress. And if I can't see if the project is alive, why should I bother to join it?

But you know it is alive, just a little disorganized. Sounds like you might be able to help that

How would one join the SCP, BTW?

If you are new to things, bug hunting is a great way to help out. If you are a new coder, and think you know how to fix something, fix it and submit a patch. If you are an experienced coder, send me or goober a PM.

[karajorma]

Might help the rest of us decide if we knew exactly what the change would entail though.

Right now I'm pretty much in the dark by what you mean by using CVS properly. I can see a lot of things that can be done better myself and I'm wondering if those are pretty much the same changes you lot are on about.

[Inquisitor]

As far as CVS itself is concerned, a more concerted effort to tag and/or branch appropriately. That in and of itself would take some time to explain properly here. Basically, you mark builds with tags that other people can go retrieve later. There is probably some elegant description in the CVS help files, I'll have to look.

The other changes relate to project focus, and you have weighed in on those

[karajorma]

Well to be honest I tend to agree that this is something we should be doing anyway.

So I'm behind that idea at least.

[chief1983]

Perhaps these CVS best practice guidelines could be added to the Wiki then, so aspiring devs would know what's expected if they want to help out with the coding?  There doesn't appear to be a whole lot in terms of development other than actually getting the source and editing it, but nothing about what to do beyond that point.