Well, Re: Fragmentation - that's going to happen anyway.

You can't tell people to be original - it's something they'll have to do themselves.

I plan on radically changing gameplay in my mod, I agree with Emon that gameplay shouldn't be changed by the OJP - but I think that certain fixes and improvements could be made without destroying gameplay (because gameplay is in shambles as it is).

Whatever I want to add on top of that is my business :)

Whatever I want to add on top of that is my business


I totally agree...
...as long as your not 99% similar to another OJP mod - which I think is reasonable to ask...

(or some high percentage - 98% would probably not be good either! ;) )

Since you plan on 'radically changing gameplay', sounds like you'll have absolutely no problem with meeting that requirement.
Can't wait to see what you come up with btw...


(because gameplay is in shambles as it is)


This is a totally objective opinion.
(I don't have one yet - I've just bought the game this second. I haven't even got round to installing it yet! lol :) )
But I've spent enough time in the Jedi Academy forums to know that there are very much two sides to that story...

Yes, there are definately two sides, and it looks like it's boiling down to patches. Some people think patches are bad, I disagree. I think the only reason it was bad for JO was because LEC pulled the plug, and Raven started working on JA. That, and **** just happens, some people made some bad choices or mistakes, it isn't garunteed to happen again.

Originally posted by Wudan
You can't tell people to be original - it's something they'll have to do themselves.

That's sort of what I was getting it, thank you for stating so. Really guys, making people e-mail you for the source code isn't going to stop look alike mods.

I agree - I am no longer suggesting people e-mail us for access to the source code initially. I'm totally down with that. I have been for quite a few posts now.

What I am proposing HAS to be organised fairly well is the releasing of NEW mods built from OJP source code.

I guess this should require some kind of request e-mail, along with the description of the mod etc.
But anyway - let's just decide what permissions are needed first. Once we know that, then we get a bit more nitty-gritty and decide exactly how they should work...

What do you mean, new mods built with OJP?

Razorace and Wudan, what are your mod ideas? I'm also thinking about a mod I'd like to do, and if our plans aren't far off, I think it would be to the best for all of us to combine efforts. Basically, I want to take what's in JA, fix it (if not fixed in patches), and improve upon it. Right now I'm thinking of scoping the E-11 and bowcaster, and bringing back some guns from DF and JK.

Blimey!
...what have we been talking about this whole time?! :confused:

Please check my very first post in this thread:


Overall, it seems the aim of the OJP is to provide a standard 'library' of bug fixes / improvements etc. That's fine - I get that. And I see the need for these bug fixes / improvements to be regulated and controlled.

Now - from what I've read - the idea is that mods are built 'on top of' OJP - i.e. using the OJP code as a base. If this is the case - then woohoo - this is great!


If this wasn't the idea, you maybe should have mentioned something earlier...

I don't mind disagreeing on things - but if your not going to read my posts properly, this makes things very difficult.

If the idea ISN'T to build new mods 'on top of' the OJP source, then I see it as a very limited concept. Sure - it may have appeal to a few developers who have very similar ideas on what they want to do. But what about the rest of us who DO possibly want to change gameplay a bit? Even drastically?

Are we just plain out of luck? i.e. the OJP can't really do anything for us?!


Emon - if you just want to get a few people together to make a mod, you don't need a big, old open source project for that, you just need to get a mod team together!!

I don't know, I read your posts, but I got confused some how.

That's definately the idea behind OJP, it always has been. I'm confused, when was there confusion on that??

LOL!

...when you said this:


What do you mean, new mods built with OJP?


I think everybody is confused now - certainly including myself!!

Tell ya what - you tell me whatever language your speaking, I'll go off and learn it (it seems to be like English, but slightly different) and then we'll carry on the conversation!


I'm sorry - I'm just getting a bit fustrated here. I think I've been making myself pretty clear...

When I say 'new mods built from OJP source code' - I mean 'new mods which use some OJP source code'. Is that clear?

Is anybody else finding me incomprehensible?!

Sorry, I was referring to this comment of yours:


What I am proposing HAS to be organised fairly well is the releasing of NEW mods built from OJP source code.

I guess this should require some kind of request e-mail, along with the description of the mod etc.
But anyway - let's just decide what permissions are needed first. Once we know that, then we get a bit more nitty-gritty and decide exactly how they should work...


In response to that, I think people should have to e-mail us simply telling us they are using the source code in their mod, so that we can keep track of it. Well, it wouldn't necessarily have to be required, but it would be a benefit to both parties if they did.

Another great thing about building mods on OJP, is that you could have levels built with new code and entities that will run on any mod built off OJP, which I hope to be almost all. :) One of the cool things about the code setup in the original Jedi Knight, was that you could add any kind of code you wanted, on a per-level basis. Q3 lacks this, and OJP could help as a remedy.

OK - I think were communicating now :)


Another great thing about building mods on OJP, is that you could have levels built with new code and entities that will run on any mod built off OJP, which I hope to be almost all.


Yes - this is a GREAT plus to having the OJP in place - totally agree.


In response to that, I think people should have to e-mail us simply telling us they are using the source code in their mod, so that we can keep track of it. Well, it wouldn't necessarily have to be required, but it would be a benefit to both parties if they did.


Yes, this is the right way to think of it.

If we can keep track of the mods which are using OJP source, then if we see two mods which are 99% similar we can just say 'Hey guys - it looks like your mods are going to be practically the same - might you consider joining forces?' It may turn out that there were more differences than we realised - or they may indeed join forces. Whatever. At least we can TRY and organise things so that overly-similar mods don't get made - because that doesn't help anybody. Not the mod makers, or the end users - the players.

Ok -so do we agree that - ideally - all mod makers who want to use OJP source in their new mod need to touch base with the OJP admins - so we can organise things? That's all I'm saying...

Sounds good.

Only reason I can see that someone wouldn't want to use OJP is the view that it's bloated, and would have large VMs. But this isn't going to affect actual speed, only load times perhaps. At least noticably. Only truely anal coders like ASk will have a problem. ;)

Actually, my idea I was thinking about would be to possibly have a couple of different versions.
I don't really like that idea. It seems like it'd be best to just keep everything in one version. As long as any beyond-patch gameplay changing aspects are done outside of BG code, we can easily make them Cvar options... i think that'd be the best way to go.

:)
Yes - the OJP code itself is going to get quite large!

People making new mods from the OJP source code are free to 'strip out' whatever they don't need though I guess. At least I don't see why this is a problem.

...and as long as all the OJP additions have been clearly marked with nice clear, searchable comments, it should be as painless as possible to do this - ideally as least...

I don't really like that idea. It seems like it'd be best to just keep everything in one version. As long as any beyond-patch gameplay changing aspects are done outside of BG code, we can easily make them Cvar options... i think that'd be the best way to go.


Well - partly, this depends on what people see as the scope of the OJP.

Seems that some people just see it strictly for bug fixes and improvements which don't affect basic gameplay.

However, I saw it as more encompasing than that. For example, I am ready to add an LMS (Last Man Standing) system to the OJP. But this - of course - DOES affect basic gameplay...

First of all, is this kind of work (e.g. LMS) welcome to be added to the OJP?

Second - assuming it is - do we release the OJP absolutely chock-full of cvars? To me - that seems like a total mess. I dont' agree with that. Pro players - for one - would NEVER play it - because they would never know what type of game they were playing when they joined an OJP server - they would rather not have the bug fixes - no matter how good - and just stick with the base game.

So splitting it up into at least 2 types of mods allows us to take on any and all 'improvements' without turning the released OJP mod into a cvar nightmare!

I don't like the multiple version idea, either. Just have internal and external releases. Internal is very frequent, external leaves out the minor revisions so people don't have to update so damn much.

Gameplay changes through cvars would give end users a little more incentive to run the mod. But restrict them to balance issues, nothing major. Through this, OJP could patch any gameplay issues that Raven doesn't or cannot get (like if LEC pulls the plug), and, hopefully, become an unofficial patch, and at the same time support all sorts of new user made levels. (Competitive players wouldn't bother with this mod, as they almost always like everything vanilla, but I personally think that kind of strict competitive play sucks anyways).

I have a lot of faith in this project. I think that if it goes the way we want, it could be the sole factor in determining the long term condition of JA.

ROP, I see your problem with the cvars, but I believe multiple mods is a bigger problem. It's confusing, they're not compatible, just... I don't like it. We aren't going to be making six hundred changes here, so it won't be a huge mess.

Emon,

Can you please just double-check you've read my last post thouroughly.

I'm not talking about different versions as in v1.0, v1.1, v2.0.

I'm talking about two different 'builds' of the OJP.

One which is limited to only bug-fixes and non-gameplay changing improvements. (Sounds like this is what your most interested in)

...and another build which could have all the other additions (e.g. LMS, extra force levels, jetpacks etc. etc.)

...unless were not intending the second kind of additions to be allowed in the OJP at all. In which case I think that's a bit limiting. And actually going against the whole 'open source' concept you've been speaking so strongly for...

ROP, I see your problem with the cvars, but I believe multiple mods is a bigger problem. It's confusing, they're not compatible, just... I don't like it. We aren't going to be making six hundred changes here, so it won't be a huge mess.


I believe the opposite.

I think it's FAR worse to have one mod chock-full of cvars, than having two builds.

Either that, or we have to think about limiting the amount - and the SCOPE of the features we can have in the OJP - which I don't think is very appealing, and goes against the idea of 'open source'...


And it's not just the literal amount of changes, it's also the SCOPE of the changes.

You seem to be under the impression no-one was going to add features which changed basic gameplay.

However, I was already planning to do so. (LMS)

If you do accept the LMS code, and you add a cvar for it, then say goodbye to the so-called 'professional' JKII players who just want to play the game as it is - no massive gameplay changes from base should be even possible.

If you still accept the LMS code, but don't include it in the final mod - what was the point of me contributing it in the first place?

If you don't accept the LMS code - then you limit the whole idea of the OJP. It would still work, and it would be fairly good - but why not allow all changes and make 2 builds?

Could you explain exactly how 2 builds will cause such confusion?! Seems pretty simple, clear and effective to me...

but again - it's majority rules here - so whatever everybody else thinks...

Originally posted by RenegadeOfPhunk
Emon,

Can you please just double-check you've read my last post thouroughly.

I'm not talking about different versions as in v1.0, v1.1, v2.0.

I'm talking about two different 'builds' of the OJP.

One which is limited to only bug-fixes and non-gameplay changing improvements. (Sounds like this is what your most interested in)

...and another build which could have all the other additions (e.g. LMS, extra force levels, jetpacks etc. etc.)

...unless were not intending the second kind of additions to be allowed in the OJP at all. In which case I think that's a bit limiting. And actually going against the whole 'open source' concept you've been speaking so strongly for...

1. I know what you mean, I know you mean different builds, and I still disagree.

2. Things like LMS, jetpacks, and whatever aren't what OJP is for, that's for the mods built on OJP. OJP is for things like new entities, bug fixes, new collision detection, maybe like new and fixed AI, and maybe very small gameplay changes to fix balance issues, making it an unofficial patch. Speaking of patches, that could be used as a guideline for what should go in. If Raven wouldn't add it in a patch, maybe it shouldn't be in OJP. Patches rarely severely alter gameplay or add new elements to gameplay, only fix them, which, as I have followed, the limit to gameplay changes for months now.

3. It's limiting, sort of, because it goes beyond the scope of OJP. We want, or at least I want it to help developers to make their own gameplay changes, not let them use ones we've created. If we go by your idea, we'll start to see some lookalike mods. And how does this go against open source? Open source just means the source code is freely available to anyone, in a nutshell.

4. "Chock-full of cvars"... As stated above, we'd only be making minor changes, there would be no more than like a dozen new cvars. I don't see that as "chock-full".

And limiting what goes into OJP is, as stated above, not against open source. This is primarily a mod for developers, not end users. Rather, it is for developers directly, end users are affected indirectly.

Ok - I see what your saying.

Basically, I've seen the OJP slightly differently than you have.

Yes, if we are limiting the OJP to non-gameplay changing features, then fair enough. We don't need two builds - I agree.

However, I'll be a bit disappointed if this is the case. I saw the OJP being a little bit more ecnompasing than that.

...but if this is the case, then so be it...

I think we can do what you want to do AND MORE with the 2 build concept. And I don't see it as confusing - at all infact! But whatever everybody else thinks...

Alright, i can see your point about having different builds, Renegade, rather than all the options... i didn't think about some of those things. But let's just limit it to two, eh? One for enhancements alone and another of additions and the enhancements. So when there's a new update that's an enhancement, it'll be implimented into both builds.

Hey, I understand what you mean. But think about it. If we make all those changes, there's no real point in having other mods, and we're going to see a lot of copycats.

Take for example various C/C++ libraries. LibXML only loads and parses XML stuff for you, it doesn't interface with your code. LibJPG will load JPEGs for you, but it won't start drawing them on cubes for you in OpenGL. Every project's got to have some sort of boundaries, for OJP, it's gameplay changes.

Alright, i can see your point about having different builds, rather than options... i didn't think about some of those things. But let's just limit it to two, eh? One for enhancements alone and another of additions and the enhancements. So when there's a new update that's an enhancement, it'll be implimented into both builds.


This is EXACTLY what I am proposing. Just 2 builds - that's fine.

All the stuff in the 'enhancement' mod would also be fully included in the 'additions' mod - exactly.

In this sense, they are compatible mods.

The ONLY reason for the two builds is because your more serious JKII gamer wants to know what he's playing when he joins a server...

Hey, I understand what you mean. But think about it. If we make all those changes, there's no real point in having other mods, and we're going to see a lot of copycats.


Not nessesarily true Emon. Not all mods will nessesarily just blanketly use all the features from the OJP. And this was the whole point of the copy-cat clause we've been talking about for a while.

I, for one - know that the mod I would plan to make from the OJP would not just casually copy ovver all the features. In fact, I'm fairly sure I wouldn't want half of them! My mod is about Movie Realism - so a lot of it wouldn't be applicable (one small example - RGB sabers - I wouldn't want them - I would only want colours seen in the movies).

If you read my first post, I used two case examples to illustrate how I saw it working.

Your analogies between libraries and the OJP only work if you consider the OJP actually as a library. It doesn't nessesarily have to be JUST that...

It still violates the idea that OJP is a mod directly for developers, not for players. What you are proposing is the opposite. What I am proposing is what Razorace and I originally thought up many months ago.

But, I have an idea. If you want to do a gameplay mod, perhaps some of the members of the team would be interested in collaborating an OJP based gameplay mod, which would be an entirely different entity. It's just that OJP itself was never designed directly for the players, and I think it should stay that way.

Yeah - I understand I may have a different idea than was originally planned. And sorry if I'm rocking the boat a bit dude :)
THat's why I made my first post in this thread so long - to make sure I wasn't getting the idea of the OJP wrong...
...I'm guessing you didn't read it! ;)


But, I have an idea. If you want to do a gameplay mod, perhaps some of the members of the team would be interested in collaborating an OJP based gameplay mod, which would be an entirely different entity. It's just that OJP itself was never designed directly for the players, and I think it should stay that way.


Well - ermm - ok. Do you mean a whole different repository, admins etc.?

...do you think that's a better solution than a few preprocessor defines?!

My idea of the OJP is still to help share developing resources. Why have 3 different developers work on similar gameplay 'additions', when it can just be put into the OJP by one, and then used by all?

Mine isn't a totally different concept to yours!! Mine just isn't limited to non-gameplay changing features - that's all.

But anyway - sounds like it's essentially end of discussion for you. THat's not what you had in mind, so that's not what's happenning. If so - ermm - fair enough I guess...!

Woah, lots of activity here. :)

I'm just going to weigh in before heading off to work. I'll be home in about 5 and 1/2 hours.

I'm voting for the 2 build system:

Basic - (Emon's) Does game side modifications ONLY. There will be no gameplay modifications in this build. It will ONLY bug fixes, map entity additions,etc.

Medicorran Enhanced - (Phunk's) Alters both game and cgame code. Also allows good gameplay additions.

To keep things under control, we should NOT cvar everything. Instead we need to just tag every major feature with comment tags to allow people to add/remove major features at will. Whither these things are "on" by default will be up to the moderators.

This means that functions will have to duplicated for the major function rewrites.

In addition, I propose that we do NOT put any per person comment tags in the code. Instead, we'll do it on a per feature basis and then list all the credits in the credits file. That way we wouldn't have person tags up the ass when multiple people end up working on a single feature.

BTW, the gameplay code sharing was part of my original OJP concept. I never mention to imply that gameplay changes were outside the scope of the project. I was simply minimizing the concept to make it clear that we only want the good gameplay additions.

Anyway, the two builds will be handled on the same repository. They will just be in seperate directories. The what's new? files will probably be seperate and the credits/rule handbook/readme files should be shared.

Off to work!

end of line.

You run a high risk of having one big ugly codebase, if you just have everybody's stuff thrown in to one big soup.

I'm really not sure what Emon thinks that the mod might be - if you want a set library of things that mod devs use to make a mod - we'll have that when the SDK comes out.

You'll find that people agree and disagree on what should or shouldn't be in a mod - the key concept of OJP (imho) is that if we all do LMS (for example), we should collaborate and make the most possible stable set of code for it - an OJP LMS module.

I think that the gameplay altering sources should be in separate files, with the best possible guide to plugging the code in to the SDK source (or perhaps a core OJP codebase), that way you won't have your gameplay changed unless you opted for it.

I know that I'm very afraid of writing a mod too similar to other OJP mods, but I'm pretty certain that it is not. I can benefit from OJP though, if it's done right.

Let's decide on how it's going to work.

Wudan,

Your right - we need to think about how - practicaly - it will work. But it can work - I'm sure of that.

I think the first obstacle is just deciding what were actually trying to achieve first! It seems to me we haven't actually decided that yet!

Once we DO decide that, then we can start talking about how we practically approach it. Many of the suggestions you've made sound sensible - for certain cases...

Well then, Razorace, you did a pretty poor job of explaining it to me in those two pages in the other thread, because I have been convinced that it's a mod for developers mostly.

If you've programmed in C++, you've probably used the STL, Standard Template Library, and you know how incredibly easy and powerful it is, and how much time it saves when programming. I think OJP should be similar to this. Let's fix bugs, make new entities, fix up the AI or vehicles, things which don't alter gameplay, but provide a good base for other developers. You all want to stop lookalike mods, but if you start putting gameplay changes in a mod that's labeled as a base for other developers, guess what, people are going to leave them in there, and mods are going to start looking the same! That's why if you leave out all but the basic balacing fixes, you can leave up originality and creativity up to people who use OJP in their mods, which reduces lookalike mods.

Also, most players aren't going to freely accept the mod if it's going to start seriously mucking with their gameplay. A lot of people like vanilla versions of their games. With my idea, OJP would keep that intact on many servers, but allow for much more advanced levels to be created.

Do you guys understand what I'm saying?

I think we need to be in a chat to discuss this. Since we're all here as it is, come to #OJP on GamesNET.

I don't know why we disagreed, but after some chatting, ROP and I seem to have come to an agreement and understanding on what we think OJP should be. I think was partly confused, and just looking at it the wrong way.

I think I can sum it up by describing the two distributions of OJP.

1. The first distribution would be a barebones, streamlined mod for developers and players. For developers, it would include all the bugfixes, AI enhancements, and anything else that mappers could use in their levels. The only gameplay modifications would be balance fixes and bugs, things that everyone would agree on. Not everyone would want jetpacks or mouse sabering, we can leave that to the second distribution.

Think of this one as a stable base for both mappers and players, but modders could use it too, especially if their mod has nothing to do with what's described in distribution 2. What was really cool about the original JK was that you could have new maps that had totally new code, and could be played with any mod. In most cases, it was something basic in concept, like a new type of elevator, a trap of some sort, etc. You can't really do that in JO without a mod, which means you can't be playing other mods while playing the level. With OJP, we can code for the mappers (on demand of what's needed in the community), we can add versatile, modular and flexible systems that fit any mapper's needs.

This lets you play really sweet maps with still a (basically) vanilla game. No major gameplay modifications, just fixes and better maps.

2. This distribution is designed for more serious changes. It's a superset of distribution 1, it includes all it has, and more. Again, every new feature has to be really versatile and adaptable. Examples could be, say, a dual wield weapon system, mouse sabering, LMS, a player class system, etc. You'd still keep most if it basic, no shockingly specific gameplay alterations, just good features that a lot of modders would want, and can adapt them to their own stuff. And because it's a superset of the first distribution, you can still run all the maps.

I don't know about the rest of you guys, but cool features in maps is really important to me. JO kind of limited you on this, and although JA is better because of scripting, it is not perfect. It's probably because I spent so many years in the original JK, I came to really love and understand the potential maps can have. With OJP and all mods based on it, you can have a map with all kinds of cool stuff that works in any mod.

As far as copy cat mods, I'm not really worried any more. Again, I remembered back to the original JK, and everything was open source, because code and hardly anything else was stored in other than ASCII. But it was never a problem! Rarely was work stolen, and if it was, it was just taken down by request of the author. I think the main reason for copy cat mods in JO is that everyone was too busy trying to fix the bugs and the balance issues, and trying to create what they thought JO should have been. The first distribution fixes that on the most basic level. No more bugs, no more balance issues, just vanilla gameplay. The second one doesn't cause the copy cat issues I thought it might earlier, because if the fundamental issues are solved, people are going to start working on the more important stuff.


So, what do you guys think? Are we all clear on this?

Sounds great Emon.
That covers it all.

Now if we are agreed on the purpose of OJP, we can move on to practicalities.

btw - I have applied to ChrisC3P0 for seperate forums and webspace for the OJP project.
He did say it sounded like a good idea, but didn't confirm anything. I'm hoping to hear from him soon.

I think seperate forums especially will be great! Trying to continue all this stuff in one thread is a real ball-ache!!

That's great, ROP. Try to get us a private forum, too.

We can host our source code at a place like Freerepository or Asynchrony, but I think having our forums and web space right here with the community is not only convenient, but functions as an ad, too.

Which brings me to my next point, advertisement. It's going to be a while before everyone accepts the mod and it becomes widespread. I think if we can get big mods like the DF mod and AotCTC to use OJP, the words "Built on OJP!" or whatever would give us a lot of publicity. I'll talk to the rest of the DF mod team, and see what they have to say. I'm pretty sure they'll agree, especially because they need the AI. Also, any code they develop could be a great boon to us, and consequently the rest of the community.

Another great example for my map thing is co-op or other gameplay modes. We can code those in, and it would make it really easy for people to make co-op or whatever kind of gametype maps. I can't imagine the popularity we would get from co-op, you've got no idea how many people want something like that! Especially if we go recreate the ents from SP, like verbatum, hopefully it could be possible to boot up most all SP maps into MP and play them. I already tried, and it actually ran, but was just missing entities.

Edit: I'll start working on a page layout and the graphics for it, more on that tonight.

The possibility of co-op is indeed very sexy! ;)

And yes - I think we need to get as much of the modding community on board as possible. At the end of the day, the more this is standard across the board, the more it benefits everybody.

Oh, and in addition to the forum idea where current tasks and whatever are listed, we have to make sure our CVS host supports checking in and out of files, so that only one person can edit a file at a time. For added safety. I think this is a standard thing, but we should check anyway.

Question, on the plan you guys came up with (which sounds just like I suggested) would Distro 1 be BG or G only? I know a lot of people want game only mods to make it easy for people to join the game. If Distro 1 is to appeal to tourny players, it needs to be game only.

I know some of my stuff (the updated animation system) requires BG modifications.

Secondly, the whole point of CVS is to prevent a checking in/out system. We want to maximize the number of people that can modify the code at the same time. With CVS, the only issue will be that you sometimes have to manually handle conflicts if someone commits something while you were doing your modifications.

BG? You mean client game modification? Yes, it would require that, but I don't care about the competitive community. Quite frankly, most of the competitive community sucks in my opinion, and they're never going to use a mod unless it's entirely perfect to their exact specifications, and is designed for exploits and tricks, something which I find stupid.

Suggestions for coding guidelines:

- All code should be as isolated from the normal code as possible. I suggest seperate functions whenever that's approprate.

If you have to alter a large portion of an existing function to make things work, make sure you leave an original untouched copy of the function (commented out of course).

- I suggest html style tags to indicate when changes are started/ended. Example:

//[AS2.0]
//code goes here.
//[/AS2.0]


Features should use analogies. Bug fixes and code improvements can probably just use something like "[Bug Fix #]" and [Code Improv #]. We can leave the explainations of Bug Fixes and such in the project documents.

- Try to document your code as much as possible.

Good idea.

You can also be extra fancy and do this:


/***************
* New feature A *
***************/


;)

Preliminary site layout from 1:30 AM, I think the comments emphasize my fatique... (http://emon.geekvision.net/OJP)

Originally posted by Emon
Good idea.

You can also be extra fancy and do this:


/***************
* New feature A *
***************/


;)

Well, we don't want to make it too complicated because some of the more complex features take a LOT of on/off tags to work. The key is to have something that is easy to ctl+F for. :D

About check in's and out's

I think whatever CVS we end up using should have some kind of check-in / check-out system. (If it doesn't have that, it won't be a very good one...!)

That doesn't mean only one person can modify a file at a time. If the CVS is good, it should allow 'multiple' check-outs - which means more than one person can have any one file checked out at the same time.

This gives the CVS extra information (person A checked out the file before person B etc.) it needs to do a LOT of the merging duties automatically. We will still need to do some manual merging in particular cases, but hopefully this should be reduced to a minimum if the CVS is good....

So, if at all possible, I'd make that one of our criteria for whatever CVS we go for - the capacity for multiple check-outs...

As a second priority, it would be handy if the CVS gave us the control to say file A can be checked out multiple times, but file B CANNOT. This can make merging easier if conflicts in particular files end up being particularly nasty.

One example in MFC programming of this we've found at work is we never let the resources.h and .rc files be multiple checked-out. Because there are bound to be conflicts, and trying to merge changes back together in those buggers is a REAL kick in the ballsack!

I didn't know that CVS has a checkout system option or that it makes a difference for the merging process. :| Oh well, I'm still new at this CVS thingy anyway. :)

Hmm...

Well, looks like the term 'multiple-checkouts' is a MicroShaft specific term.
(I mainly use Visual SourceSafe)

In CVS, the equivalent is basically an unlocked system which merges in changes the best it can.

...but since people don't have to 'mark' when they start altering a particular file in the unlocked system, I don't think the auto merge function will be able to get it right as much as the 'multiple check-out' system I'm used to does.

...the end result being we'll have to do a bit more manual merging than I'm used to.

Plus there is no record of who is working on what file! (Is that correct? That gives me shudders!!)

But, looks like this is how it is for online, free CVS - so, oh well!

Looks like it has to be a totally unlocked system then!

...gives me the creeps a bit. (It's fairly different to how I'm used to working), but what the hey!

Yeah, we're going to have to experiment with the system a bit to figure it out.

I'm mainly worried if the commit function does a update scan before attempting to commit. Otherwise, we could have accidents where recent revisions are reverted when someone doesn't update before commiting.

I would CERTAINLY hope it does! Or we could end up in SERIOUS s**t!

To me, it seems like going about things backwards anyway.

Surely it would be easier to make the user at least mark when they start working on a file. (And at the point of marking, your forced to get the latest version of that file from the repository).
That way it wouldn't need to do a scan to determine if they have updated when they should have done - it knows if any other changes have happenned on that file independantly in the mean time and can force a merge...

but oh well. We have to work with what we have avaliable...

Yeah - we defineltly need to do some tests...

If we do these tests, and we find that it's fairly easy to start writing over other people's changes accidently, I think we may have to consider restricting it to (single) checkout's.

...either that, or discover a new, better - but still free and online - system.

I know, I know - it would end up being a REAL pain in the rectum. We tried to keep it to single (locked) check-out's at work initially - but it turned out to be too much hassle. And we were only 4 of 5 guys who were all sitting in the same room!

Were potentially talking about many more people scattered all over the globe!!

(But remember, at work, we had the alternative of the multiple-checkout system - which is NOT exactly the same as totally unlocked, it's quite different in many important ways...)


But what's worse? Causing people extra hassle when they have to wait to check out a file, or leaving open the possibility of having work totally erased from the respository if people forget to do updates when they should? (And with the number of people potentially working on this - I think it's VERY safe to assume that's going to happen at least ONCE...)

But anyway - we do need to do these tests and see what the deal is. But if there is ANY doubt - I think we HAVE to consider (single) checkouts - i.e. locking the respository...