Open-AudIT

It would be really nice if we could get a subversion setup going or some way to submit patches for Open-AudIT. I know there were some great modifications going for Winventory, and I would like to see them make their way into the official source. Not only can the community make Open-AudIT better, but when it comes time to update our installs, subversion can update our files while keeping any personal modifications. I know you may want to get Open-AudIT feature complete before you do this, but hopefully you have plans for this in the future!

I know that I've asked mark for this both in the winventory forums and via email. Thus far the response has been a mixed bag of "I'm to busy to figure it out" and "I'm afraid of loosing control". As it stands there is little point in community efforts as we will always be working on out of date code. Patches can be suggested, line number marked, diffs posted, but in the end whatever we've been working on might not even exist anymore on the working code base.

Mark please, you're tying our hands. I really really appreciate the work you're doing here. I know how much trouble, effort and time this is. But if you ever want to leverage the community of programmers and IT folk out here that use your product this is something that you NEED to do.

There is so much I see in Open-Audit that could be worked on, so many projects for the advanced programmers or the novices ranging from html clean up to refactoring and right now none of it can be done. I'm sitting here today at work, thinking about implementing open-audit, but knowing that if I do I'll want to fix these bugs I find, and if I fix them that work will be repeated a million times by you, by other IT folk, by myself, because I can't post to you effective and accurate diffs.

SO Please please please, either ask one of us to help you set up a public SVN/CVS server, or ask us to help you understand your own install, or do it all yourself. But when you do the wealth of help that is available to you is magnified enormously.

~ Anders

He already has a SVN page on sourceforge, so we could just use that (though I am really not impressed with how often it is working -- I often get errors trying to access: "503 Service Unavailable", although maybe the actual svn server is running, that's just the web access). My guess is that he just has to set that up for access by others (and maybe make a new branch for submissions so that they don't immediately go into the production version).

Oh, and I hope Mark does it. That's the only way he can maintain control. Otherwise maybe there will be a fork of the project. I'd hate to see that happen.

yup, the sourceforge svn, though flakey, would be an enormous step up. And probably easier to manage than trying to get one set up with another hosting company.

OK then - who wants to help me on this one (as well as provide some basic tutition) ???

I have played with Subversion a couple of times, so I know the very basic stuff.

I did setup SVN when I created the SF project. Whomever wishes to help, let me know (maybe PM me). I'll make you a member of the SF Project, and send you a copy of my (current) code. You will need a SF account. You can then upload/setup SVN on SF, and give me a heads up as to how to use it. I think we should restrict SVN upload to approved users (yes ?).

Let's do this. I want Open-AudIT to be more successful than Windows Inventory. I am a firm believer in "more eyes = less bugs", and I'm sure there are many more knowledgeable people than me out there willing to help.

The first thing we need to do is determine which files to version. Files that are installation specific should not be versioned, otherwise our files will constantly be different (example, the include_config.php (IIRC)). Files like this will have to probably be generated/renamed by the setup.php. That's assuming people download using the svn repository (which I imagine they would, since it would be the most up to date). Also, you should set up some rules for us to abide by, since you are the guy in charge. We'll also have to come up with a system for determining who is working on a bug fix, or else multiple people might patch the same bug.

OK, I have some ideas - I'll get them on paper (virtually).

Yes svn commits (uploads) should probably be limited to a select few "developers" who can do code reviews (that is, knowledgable enough about the code base not to break anything) at this point I think that is likely limited to yourself and maybe a few others from winventory.

I'm not familiar with sourceforge's own svn setup but would be happy to help in any "general svn" way.

mikeyrb is right, as I've mentioned elsewhere we will in the future want to get a real bug tracking system be that mantis or bugzilla or some other application. I don't think this is on the forefront of necessity however. Being as how right now the developer base seems fairly small, and the number of people qualified to commit changes even smaller.

~ Anders

I might also suggest a gui for svn, since I find them nice to use (especially being able to to a diff on file versions to see what changed). I've used tortoise svn on windows, it worked nicely. However, I don't know if there's anything like that for Gnome (there is some svn thing for KDE). I did notice RapidSVN (which is in the ubuntu repository), which might work well.

In my experience, RapidSVN is everything but rapid. The commandline svn command is much quicker.

command line svn is also a huge step up in clarity from cvs. If you're used to the confusion of cvs giving command line svn a shot is worth it.

~ Anders