View Full Version : Subversion Repository

07-16-2007, 10:38 AM
Does osCMax have a public/private subversion repository?

I think one of the things I find frustrating about working with osCommerce as a whole is the amount of comments and jumbled code that ends up all over the shop (erm....not funny) that could be removed and still maintained using version control.

It also seems and that lots of people have solutions to problems that could be commited to a private branch for merging with the main project, and would probably save lot of other people who are willing to hack the code quite a bit of time. For instance I have had a few solutions in the past I'd quite like to hand back to others and this might be the best way to do it.

Or is this a silly idea?

07-16-2007, 07:49 PM
It is a great idea, and I am all for it actually. I just have not had the time to set up a repository on a public server. It is a bit beyond my skill set to be able to set up a secure repository with public and private access.

If you or anyone else wants to volunteer to set up the repository, let me know and we can get things rolling.

07-28-2007, 12:38 PM
Well, since noone else volunteered and I've just discovered that google themselves do subversion hosting I have set up a respository and I'll be importing the latest release code base into trunk and tagging it as the latest release. I'd really like to get this going and will help where I can to do merging, organising, testing. I think osCMax has alot to offer and this could help speed up and improve delivery of bug fixes.

07-28-2007, 09:44 PM

Before you move ahead with this, I would like to maintain administrative control over the repository since I have grown quite attached to the project, and want to assure that osCMax continues to move in the right direction.

I added a project over at google code (I just noticed that you did too...sorry about duplicating effort there).

Ok, so who should be allowed to commit to the repository?

07-29-2007, 12:20 AM
Sorry, wasn't trying to jump the gun and assume control :) I can see that you've now got an oscmax2 google code repository now.

The way I see it, all of the clean/working code (or as far as we can test for) should go into trunk and at stages where a particular feature is deemed finished or release finished it should be tagged with the version number.

If someone wishes to work on a feature or submit a bug fix a copy of trunk should be copied to branches/<username>/ and they should checkout that branch and make all commit back to that. No one should commit directly back to trunk it should only be merged by the repository admin so they can decide if the changes were indeed a fix, correct or necessary. Perhaps only fixes initially should be allowed because there might not be a publicly accessible roadmap for the project

I haven't look closely at google code to see how much flexability, or whether you can limit write access to certain branches to certain people, etc. If you can that's great. But if you only allow members to contribute and you are sure they are all working on their own branches it could work well.

Anyway just a few ideas :)

07-29-2007, 04:33 PM
How Google code works, it looks like only members/admins can upload code. I will have to play around with it to see exactly what can be done.

I have added you as a member of the project, so if you want to test out creating a branch for you to work on, feel free to do so.

I do not see any methods for restricting access, but as long as we (all coding members) agree to some basic ground rules as to how changes will be added, I think trust will be good enough.

I like your thoughts on creating branches for members to work on, and only committing to the trunk after testing the branch. I am going to test out how to do this through Google and hopefully we will get a good procedure going.

07-29-2007, 06:12 PM
We sort of discussed it a while back as well - but I have had other issues to deal with the last year and a bit.

I setup a Demo site a while ago and has started playing with SVN and CVS etc...

I tried a few client server version like: CVS, SVN and OpenCVS but did not go much beyond that at the time. I did not look much at Distribution type - due to the lack of control and branching control that could (potentially) go way out of whack.

I have not looked into other hosted solutions.

07-30-2007, 06:26 AM
Ok, looks like we are getting things rolling. I have made my first attempt at a branch and so has pigdestroyer.

Next, I have started the RC4 branch, and currently I am working on adding in all the updates from osCommerce.com to bring the code up to date with the MS2 RC1 release. I am about 60% done with it, and should have it added to my svn branch sometime this week.

Jason, pm me your gmail address and I will add you to the mix :)

07-31-2007, 11:56 PM
Just an update, I have finished adding in all the osC bugfixes up to the osCommerce 2.2 RC1 release and the code is now up to date. I will be commiting it to the RC4 branch Thursday or Friday for testing if you want to grab the files then.

08-06-2007, 05:57 AM

I have some experience with Subversion, including hook scripts which can be helpful in matching commits to bug tracker entries and/or task manager entries. If you like, I would be happy to lend a hand here.

I beleive version control can be quite helpful in building code quality, though my experience is that without some structured approach to documenting code decisions the value is seriously degraded.

I can in fact, manage a complete SVN server installation if necessary.



08-06-2007, 10:29 AM

Your offer is most welcome. I think we will be sticking with google code for our repository, as that lowers the overhead of the operation significantly. If I find that it falls short of expectations, we can always set up our own server.

Regarding structure, I want to maintain pretty tight control over branches and merges to the trunk. Since everyone that gets write access to the repository will be trusted to follow rules regarding trunk commits, I don't think that will be too much of an issue.

We do need to start mapping out the development future of osCMax in more detail though.

JPF has taken the lead on code change documentation and has really made great strides in keeping changes consistently documented. I agree, though, we will need some published framework that all developers can reference when working on branches.

Regarding a hook script for our bugtracker, that is the next thing on my list. I checked out SCMBUG, but it is not really an option with google code from what I have read (correct me if I am wrong!). I am definitely interested in your thoughts on how to accomplish this. Let me know your ideas and what you would need to take the lead on this type of project.

08-06-2007, 12:02 PM

I wouldn't suggest moving if you can at all avoid it. Doable, but why incurr overhead against your development time?

It would help if I knew for certain what bug tracker you are already using. Seems familiar, and if I am right in my suspicion of which package is being used, you may have little trouble integrating hook scripts for it. I'll be taking a closer look at Google Code in the very near future, and will get back to you with any comments or suggestions.



08-06-2007, 02:27 PM
We are using Mantis...

08-08-2007, 04:58 PM

I thought so. Course, I also thought I responded to this two days ago...

There are a few nice references to Mantis hook scripts out there... - more research.. :)


08-22-2007, 01:42 AM
There is quite a nice article on Mantis hooks here, in case its of any interest

alt-tag.com » Blog Archive » Integrating Mantis and Subversion (http://alt-tag.com/blog/archives/2006/11/integrating-mantis-and-subversion/)