Also consider this:

With a locked checkout system, individual users don't nessesarily HAVE to wait till that file is checked back in...

You could just go ahead and adjust that file locally anyway - even if it is checked out. Just make sure you mark each of your changes well.

Then - when the other user checks back in the file you need, you make sure the file you were working on is backed up somewhere.
Then you check out the file you need, which means getting the latest file from the repository with all the other users changes.

Then you merge it manually your end - finding all your changes in your backed up file and putting them into the latest file from the repository.

OK - it's more hassle. But at least the repository is SAFE.

...put it this way, I'd personally rather go though the kind of hassle mentioned above than have a potentially unsafe repository...


I know we haven't done the tests yet! But I'm just getting down all the possibilities just in case the tests expose problems with a totally unlocked system...

Feh. It's going to require COORDINATION. Which is why I say the bulk of your functions should be in external files, for instance, if I made a new file for g_ code, I'd call it g_wu_whatever.c - and I'd have some step by step code pastes for hooking it up to the main codebase. It's the least ugly way to go about it.

Every other way, checking, single code-base, etc - they just seem too problematic and klunky. I just want to code.

Wudan,

I totally agree - external files...
...WHERE possible!

But many alterations can't be nice and neatly bundled up in seperate files.

I certainly see very little of the changes meant for Distribution 1 being able to be kept to seperate files.
Maybe more in Dist. 2 could be neatly packaged up in sep. files, but I seriously doubt ALL will...!

If the change requires all sorts of little code changes all over the place, you can't put them in seperate files!

So we need some kind of CVS system. I don't think this is in doubt. THe CVS system is meant to give you the co-ordination you mention - that is it's whole point!

And it obviously works! No big, complex open source project COULD work if CVS didn't!!


Were only talking about the specific details of the setup of the CVS system here...

Safety of the central resository vs. the convinience of the end user.
Personally, I think the safety of the respoitory should get top priority...

Wudan, doesn't your idea make it a pain in the ass to put stuff back together? What exactly is wrong with just adding to the regular code, as long as it's neat and well documented?

ROP, what exactly do multiple checkouts do? Because I'm not quite getting it. How do you have two people checking out one file, and still get the new code from each person when you merge it? Wouldn't one overwrite the other?

Multiple checkouts (in Visual SourceSafe) are 'similar' to an unlocked repository, except you still have the concept of checking out.

Checking out a file doesn't stop other people checking out that same file, but it means:

a. When you check out, you get the latest file from the repository. THis means that the system knows at what point you started altering the file, and what state it was in when it gave it to you.

b. When you check the file back in, the system has an exact record of who changed what and when inbetween. So it doesn't need to scan the file your checking in to make sure you have any alterations you should have. It KNOWS straight away whether you need to do a merge - because it knows when you checked out, and if anybody else has checked out AND in since then.

At this point it would attempt to do an automatic merge. As long as their are no conflicts, it can handle all this automatically. You only have to start manually merging stuff in if there are conflicts - but this doesnt' actually happen as often as you might think...


It's probably best not to think of multiple checkouts as checking in and out as you know it (i.e. totally locking out other users) - it's more a system of marking when alterations are made by different users -combined with automatic code merging.

It's an unlocked system in the strictist sense, but it's a very safe and organised unlocked system.
I know it works - I've used it pretty much every day for the past 5 years!!

But anyway - this is probably irrelavent anyway. Sounds like the CVS system were using doesn't have this 'marking' concept - at least not to the same extent (and SourceSafe obviously isn't free!) - so we have to make do.

And who knows - maybe this system CAN accurately work out when things need merging and make sure someone can't just overwrite stuff. We can find this out through some fairly simple tests

If this is the case - all is good...

Oh, that's cool. I think Subversion (http://subversion.tigris.org) is adding that in future verisons, they are aiming at replacing CVS.

Subversion looks cool.

I don't think it does anything like the 'multiple' checkout stuff I've been talking about (at least I couldn't see anything like that in the description - current or planned...)

But it looks like it's an overall improvment on CVS in some areas...

I think I've had it lucky using SourceSafe! Seems the free, online stuff is either fully open or fully locked down - no real inbetween...

You think SourceSafe is pretty good eh? I've heard horror stories about it, and I've heard it's one of the few things Microsoft has gotten right. Oh well.

CVS should be fine. We're only a mod team, I don't think we need much more.

Well - don't get me wrong - it has it's problems. Things can start to get unglued when you start branching stuff AS WELL as multiple check-outs! lol - but that's just asking for trouble anyway!

At the end of the day, we've had very little trouble with it at our place.
Were certainly not worried about work being over-written in the repository - AND were not restricted to single check-outs...

Yeah - CVS will do the job. But if we think it might be likely that we could over-write stuff accidently, I think we should just bite the bullet and lock the repository down. With no 'inbetween' to choose, I think that's the best alternative.

...that's just my opinion though.

...and we still need to get it set up and do the tests first anyway...

Correct. I'll look into Asynchrony today. There are some other places similar to SourceForge, but I don't believe they will approve of our project, as they are all true open source. Asynchrony hosts closed source projects, infact there is no approval, it's instant.

What's the news on our hosting? I'll have the page done today.

If, for some reason, JK.net cannot host us, Kedri at Massassi made it quite clear last I talked to him that he would be fine with us being hosted over there.

I'm still waiting for a reply from ChrisC3P0.

I've just sent an update request message to him...

I have a repository with CVS (as in the cvshome.org version) @ freepository.com set up. It just needs to be tested now.

Say, here's a idea. Why not make a universe cvar list while we're messing with stuff? A simple cvar.txt in the documents folder would do the trick. You could simply add descriptions/cvars when you discovered what they do.

sorry... i've been out of the loop here for some time, but this project sounds like it has a lot going for it. I'd like to assist if possible.

It seems to me that if you're going to create an "Open Jedi Project" then it should actually be open, in line with the concepts of Open Source. If it's not really open then it's probably a good idea to call it something else. Additionally it would be necessary to give consideration to the Raven/LA license. However, as wudan mentioned, definitely requires management of the changes, but the changes would be subject to approval, etc.

I'm sure you already know this, but with regard to CVS, it's quite a radical change of concepts from VSS. I've been a VSS user/admin for quite a while now, and we're moving to CVS in our organization. The idea is that you don't actually check out files like in VSS... a "check out" in CVS is akin to a Get in VSS, which can be a bit confusing. The merge happens after you work on the file locally.

But getting back to the concepts of the project, it sounds like it's going to be a great asset to the mod community.

Well, I got bad news. After checking out the freepository.com system some more, I don't think it's going to be what we need. Getting direct CVS access in Windows is INSANE. You'd have to install a CYGWIN shell and crap and that is too goddamn complicated. In addition, the webpage system is far too primative to be useable.

I'd say our best hope lies with sourceforge since their system can be easily accessed with WinCVS (as far as I know). I know I've seen a JK2 mod on the site so I don't think we'll have a problem getting it there.

Or, we could try getting someone to manually host a CVS server for our purposes.

I've got a message back from ChrisC3P0.

He says he can give us hosting. He can't set up the forums until the website is up and running. (That's the policy).

So - Emon - you may want to get in touch with Chris directly to sort out the website. Just send him a quick PM I guess.


recombinant,

oooo. Someone who has used a 'normal' CVS system AND VSS. Cool. Maybe you know of a free CVS system appropiate for what were trying to do which has some kind of 'multiple check-out' system - or something equivalent...
(btw - Did my explination of multi checkouts make sense?)

About the 'totally' open thing - well - again, I'll go with the majority. Maybe it's even just a case of not calling them 'rules' as much as 'guidelines' - or whatever.

Bingo! 'normal' CVS does a check to make sure that you don't accidently revert someone else's revision if you haven't updated before committing. I believe that commit will not work (gives an error) if your code isn't 100% up-to-date with the CVS repository.

http://www.cvshome.org/docs/manual/cvs-1.11.6/cvs_10.html#SEC83)

Unfortunately, you need direct access to teh CVS system for this to work (since the program has to store a lot of data locally to do this) and freepository.com's method for direct access is too complicated for our purposes. Hell, I'm not even willing to do it. It involves installing a unix shell and crap. Not worth it. :)

We need a repository where we can use winCVS or something that's easy. Since it sounds like we're going to 100% open access, security isn't much of an issue.

AHA!

Yes - 'unreserved' checkouts sounds like the CVS equivelent of the 'multiple' checkout concept I'm used to.
And it looks like it's (reasonably) safe. I'd still be wise to do quick tests, but at least the concept is there...

Phew! That's a relief!

OK - so now we just need to find a system that isn't a total nightmare to work with...?

See, I was pretty sure that was the situation. The book I was using was written in tutorial form so it was like impossible to just flip thru and find specific information on the commit system. The 4:00am tired didn't help either. :D

Anyway, I'm hoping that sourceforge will accept us. I'm pretty sure WinCVS works with it.

Yeap - sorry Razor, you were right - it was just a difference of terminology...

Reserved and unreserved (CVS)

as opposed to

single and multiple (VSS).

It'd be nice, recombinant, if you could confirm that for us - since you seem to be familiar with both systems. BUt certainly looks like it to me from the stuff Razor has just linked to...

mmm starting to sound good mmm

RECOMBINANT!!! Where've you been?

Originally posted by razorace
Anyway, I'm hoping that sourceforge will accept us. I'm pretty sure WinCVS works with it.

Yes... for Windows systems it seems that WinCVS is sort of the standard, and Sourceforge's system evidently works well with WinCVS. It's definitely not a trivial setup, however, and it can be a challenge. I'm still working on it. ;)

Honestly, I've only had a little experience with CVS so far, and I'm not the CVS admin at work. However, there are a few people here I can use as resources, since they've used CVS, specifically with Windows as a client.

I'm very familiar with multiple checkouts in VSS, and it's a similar concept to CVS - basically more than one person checks out a file and VSS attempts to merge when you're done. If it can't figure it out, you get the esteemed privilege of doing the merge manually. :D

But CVS basically lets you work all you want - there is no real checkout per se like VSS ("Hey, I'm working on this file and you can't have it until I'm done!"), but that's the whole different mindset behind CVS. VSS' multiple checkout system is the closest analog.

Sorry I couldn't be more help at this point... if I find out more I'll let you know.

:D

Originally posted by Wudan
RECOMBINANT!!! Where've you been?

Oh, I've been lurking about.... lots of stuff going on and I had to drop some extracurricular activities to maintain my sanity.

BTW, we released the software product I've been working on since last year (remember my month-long disappearance back in March???).

...and of course we're now working on version 1.01. ;)

OK - thanks Recom.

Well - from what I've read, I think the ideal set-up in the CVS system would be 'unreserved' check-outs.

I guess we just need to give it a thorough testing and see how robust it is. It sounds like it should do the job...
at least if it does what it says on the tin :D

I'm still betting that we have to do some lean mean manual merging before the sun sets on this project.

This is a bit offtopic but, on JK2 section of PCGM, there was a OJP zip. The guy had a fit, Sergio/Eldritch changed it to Saber Hilt Pack. The zip is still called "ojp.zip."
Once agian, sorry for off topic.

The components that will be in both distros will probably have to be manually merged (partially) once distro 2 changes significantly from distro 1.

But, hey, it's better than doing everything manually. :D

Originally posted by Hellfire Jedi
This is a bit offtopic but, on JK2 section of PCGM, there was a OJP zip. The guy had a fit, Sergio/Eldritch changed it to Saber Hilt Pack. The zip is still called "ojp.zip."
Once agian, sorry for off topic.

Thanks for the update. We already knew about the name stealling but I didn't know about this new file until now. I'm still talking to the admins about it. :)

...well...

There are two ways to approach the two distributions.

btw - can we give the two distributions / builds different names? 1 and 2 don't really tell you much. I'd suggest:

Dist. 1 = OJP Base
Dist. 2 = OJP Plus

...or whatever. Someone can probably come up with better names...

Anyway - you can either keep the two distributions totally seperately. That means your eventually going to have to merge Dist. 1 (OJP Base) into Dist. 2 (OJP Plus) whenever we need to do a new release. Could be a bit of hassle.

The alternative is to put ALL changes into the same code base - but wrap up all OJP Plus stuff in a preprocessor #define. Something like:

#ifdef _OJPPlus

/* OJP Plus feature */

#endif


NOTE: This is how extra debug code is handled. It's wrapped up in _DEBUG preprocessor defines...


Then, all you have to do is set up two pretty much identical projects in VC++. One with the OJPPlus define, and the other without. No big merges needed.


Again, this is pretty much how debug and release work. The release build does not include the _DEBUG preprocessor define


We can ask individual contributors to wrap their features themselves, but some will probably miss it - so I think the admins would need to check each new feature and do this if it's been missed. I'm quite willing to do this myself. This won't be that hard as long as you can check the history and see exactly where the differences are (Personally, I'd find this less hassle than doing a massive merge each release time)
And at the end of the day - we really should be checking each feature anyway - for many other reasons too...

I also see this as a safer method...

Two different respositories and merging could still work. But I see the preprocessor define way as neater, and also less overall hassle...

I don't know. I think two seperate code branches would be easier in the long run. I imagine the plus version will have a LOT more code in it than the basic version. Forcing people to do a crapload of ifdefines around all their plus work would be a big hassle. Having to merge stuff semi-manually (you can merge branches into the "main" project with some automation) would be a lot less work overall.

I suggest we simply make the basic version a branch of the primary code trunk (the plus version). That way we can add whatever we want to the basic code and then easily merge that data into the plus version.

As for actual binary releases, we could just release them seperately or as a package. A package deal would probably be best to avoid jedimod/jedimod++ confusion.

In addition, I suggest we only use MSN messenger for realtime communication. Idling in a IRC channel waiting for people is too much of a hassle.

My MSN messenger address is razorace@hotmail.com. Feel free to contact me if you need something.

Originally posted by razorace We need a repository where we can use winCVS or something that's easy. Since it sounds like we're going to 100% open access, security isn't much of an issue.

I'll look into my sources. Bwahah!

I'll finish the website today. The page on there now was an old test, I seem to be in a paradox of finding the perfect method for rendering the page on all browsers, so I said screw it, I'll just use tables or something. CSS layers can bite me.

ROP, when I put together the site, I'll think of good names for the distros.

Razorace, either MSN, ICQ or AIM, whichever most people have. I say not MSN because MSN is supposedly going to not let third party IM clients work with their protocol anymore, and there's no way I'm using theirs. I still think IRC is better, it's especially great when we all have to talk at once. We can use IM for just one on one, but for a team meeting, IRC is a must.

Yeah- I say use ICQ...


About how we manage the two builds, well - I'm not overly fussed at the end of the day.

I would have thought that we would really need to double-check all the features going into the OJP anyway - between us. In that case, the #define way wouldn't really be much extra hassle. You'd get pretty used to adding the #defines quite quickly I reakon...

(Again - I may be assuming too much about the CVS system. In VSS, it's very easy to quickly scan through and see ALL the differences between new code and the old code. In fact, standard procedure is to peer-check someone else's code before they can add it. We could still check aded stuff - only we'd have to do it after it's been added. But that's better than nothing...)


If were NOT checking each addition - well - then I guess the branching method overall WOULD be better.

...but even with the two branches, it's possible that someone may put a feature in OJP Base, when it should be in OJP Plus- or vice versa. If were not checking each feature, we could easiely miss that.
But then I guess you just deal wth it at the time.

Ok - well - either way will work. I'm happy enough to go with branching...

I'm suggesting MSN because it supports multiperson conversations easily and quickly. As for the third party blocking, I think M$ gave it up. My copy of trillian runs MSN perfectly.

CVS does allow for diff checking. I was simply suggesting a branched system as I know that the process for merging code from the branch to the main is at least partially automated. I'm not so sure that would work for completely seperate modules.

I still would prefer IRC, and I think some others here would, too. Especially since you can just use an applet on the site and not bother with any client.

ICQ supports 3 or more way conversation doesn't it?

Anyway - I'm not too fussed - although I prefer ICQ, but I'm easy.

An IRC channel would be way cool...

ICQ supports multi recipents but A) that doesn't work as well as a real conversation chat and B) doesn't work in Trillian.

I don't like IRC because there's no way to tell if someone is online or not with idle whoring all the major channels

Sides, if you're too lazy to install MSN or trillian, you're probably too lazy to install WinCVS, and therefore too lazy for the project.

WHOIS reveals idle time on Holonet. :D But really, it's not going to be that important. If he's idle, he's not talking now is he?

I was fooling around with some graphics, and I got the following. The black box is where the ad would have gone.

http://emon.geekvision.net/OJP/template.html)

Mozilla = Great.
Opera = Great.
IE = TOTALLY ****ED UP! :mad: It can't render PNGs with transparency, WTF

Idle time or not. I don't want to have to have an addition window open just to idle until there's someone to talk to. Plus, this constant virus/portscanning crap when I connect to the network is pissing me off.

I use IE and I seem to see everything, it's just that none of the buttons are pressable yet.

The banner isn't ugly and white?

It's white but it looks pretty good as is. Now if only the buttons worked....

I'm casting a vote for IRC.

Well - looks like IRC is the fav.

Although I agree with Razor - I think it's a pain in the arse it doesn't automatically detect when someone is idle and give you some kind of an audio alert when someone joins or becomes active again.

I easiely find myself stepping away from IRC for a sec - getting distracted - and then suddenly remembering I'm idling in the room - check, and find I've missed loads of the conversation.

...so to avoid missing anything, I have to keep bringing the IRC window to the front again and again and again and again and again.... zzzzzzzzzzzzzzzzzzzzzzzzzzzzz

...but oh well. I can deal with it...
*sulks* ;)

Well, tuff, I'm not going to idle in some channel all day so you guys don't have to install trillian or MSN. If you want do the IRC thing, that's fine, but I'm sticking with the IM services. :P

Um, ROP, I can think of two solutions for that.

1. Scroll up.
2. Look in your log file.

...yeah...

Emon,

Depending on how long I've been away, that's a LOT of catch up, which wouldn't be nessesary in other chat programs.

...I just think other chat programs are far more practical - and just make more sense.

...did the maker of IRC not know how to trigger a sound?!

Anyway - whatever. I think it'd be hilarious to have agreed this much and then not be able to agree on a friggin' chat program!

...so in the interests of sanity (namely mine), I'll leave it up to the rest of you! I'll use whatever...

Um, how is that different from catching up in an IM client? If you're doing 1 on 1, then obviously they are waiting for a response, same in IRC... If you are doing a chat on MSN, then what, you can wait for the person to get back? You can do that in IRC, too. Just ask the person. I don't understand what is so hard about that...

And most IRC clients let you do sound triggering for all sorts of events.

A. If noone is around, you don't have to have a freakin' window open all the time.
B. It has a consistent user online alerting. You don't have to worry about the person changing nicks and so on.