What do the developers think of the idea of abandoning SourceForge’s CVS repository and switching to a Subversion repository on www.oemr.org?
Problems that I think this would resolve are:
(1) SourceForge’s anonymous CVS access seems to be unusable most of the time. This is quite annoying for those who want the latest stuff but are not project developers.
(2) Subversion has many improvements over CVS which are listed at http://subversion.tigris.org/. Especially compelling for me is the ability to version symbolic links, directories and renames.
The main gotcha that I see is making sure someone will always be available to do administration: i.e. backups and troubleshooting. I would not want to be counting on just person with that responsibility.
Also some people may get confused by failing to read whatever notices we put up, and thinking that SourceForge has our latest code. I’m not sure offhand what the best way is to address that.
I know SourceForge is working on Subversion support, but it appears to be at least 2-3 months away and we don’t know what new problems it might come with. We could plan to switch back when and if they do get it all working.
i have another server that could be used primarily for backups.
It seems that a cron job to run regular backups on a daily basis would be necessary.
Ultimately, all of the develpers would have independent emergemcy back-ups as well.
I could set up the second server at my office in a DMZ. A cron job to run backup the svn server could be run at regular intervals. We could also mirror the web page on the same machine.
This would give convenient second location back-up of the svn tree.
I will need assitance from you or the other core developers in checking out the set-up and assistance with administration of the svn repository.
Once we release files we bundle them, post one copy to the oemr.org web page and one copy to sourceforge.net. So sourceforge would still have the freshest stable package and their could be anonymous svn access for those who want or need bleeding edge.
I will say either way is ok to me,
I sort of like sourceforge, but the users realy need to get what’s the last.
a cron job can generate a tarball to download.
I can write the script if you want to start with that,
If we did switch to svn, then we should also change the link on the sourceforge site to point to whatever server was the code repository, change the default cvs page or remove it all together and just have the link on the openemr.sourceforge.net page so that others wouldn’t get confused.
Hey guys - seeing how its been 4 years - I think Sourceforge has the kinks worked out with SVN.
Are there plans to move to repository to SVN? Being a developer, I’ve tried to pull thie source code back, but the CVS client and usability is horrible. I always get errors when connecting anonymously and the visibility of the changes is really hard to see.
I see there is some kind of sftip sandbox in SVN, but I haven’t seen any information on how to connect to it. I know this isn’t the latest code either.
I know this is a reply to an old thread, but I did a search for SVN and didn’t find much information out there as to why you guys are still running CVS.
We’ve talked about this and there are no objections to SVN. The only thing is that we have automatically updated demo systems and a developers appliance that Brady handles and the work load to switch those to SVN is too high for him to handle right now. As soon as Brady is ready or someone can help him with that we will move forward. I pretty much hate CVS, myself.
-Tony
I would love SVN over CVS. However, SourceForge now has support for Git, which I think is vastly superior to either, particularly modern (1.6+) versions, which support MS Windows quite well.
Before OpenEMR switches version control systems, please watch (youtube) or read this Google TechTalk. Basically Subversion’s “CVS done right” might not be good enough and we should consider our other option. The speaker is no longer directly involved with the Git project, and the talk is from years ago (Git has only improved since then), but it is still fairly convincing.
I love being able to branching/merging without access to the server. I also think that handling merges-even ones that can’t be done automagically-with Git is vastly supperior. I use Git to manage my OpenEMR checkout, and will continue to do so if we move to Subversion, but there are advantages to having the whole project on Git as well.
Score another point for Git. The git binary has a ‘cvsserver’ mode where it acts like a (read-only?) CVS server. I can write the scripts to automatically refresh a Git repository from the SourceForge master, start up a “git cvsserver”, and have the developer appliances pull from that.
I’m open to switching to svn or git. But not a big deal to me, I’ve used several different version control systems and cvs is not hard to use, especially now that SF has made things faster. Let’s wait for Brady to get around to it, and in the meantime we can continue to discuss svn vs. git.
In theory, I have no preferences (although, I’ve heard that git has improved functionality but has a steeper learning curve, which could be an issue in our project with beginner developers; although the easy support for Windows users would be very useful).
The issue is that all the cvs demos (3.1,3.2, and 4.0) are based on the Developer Appliance, which has a hard coded request for the cvs on the sourceforge server to collect the most recent cvs versions on appliance startup. To change this would require re-building and re-deploying them all. It would also require a rebuild/redeploy of a new Developer Appliance version, and then the current Developer Appliance would be break for current users (I’m not sure how many people are using it, but this isn’t ideal).
My time is very limited secondary to my day job, so I wouldn’t even be able to think about doing this for another several months, And to be I honest, I don’t want to do it, because it’s a tedious process (also need to do lots of testing) and there seems to be no benefit? I’d rather spend my limited time on stuff that is more enjoyable (the benefit to being a volunteer) and productive like reviewing/committing code and helping to work towards MU. Are there any notable disadvantages to CVS that are worth this change (coldblood’s issues don’t count, because the cvs does work on SF, is fast, and is reliable; coldblood’s issues are likely related to the cvs client software)
As someone who has run projects based on cvs, svn, and git, I believe we should switch to using git without delay. While I’ve had some minor problems transitioning due to VERY bad practices by previous developers, using git ‘correctly’ has noticeably improved the quality of the patches I write, while allowing me to write more, easier.
I would also love to see the code base migrated to git, enough that I’d be willing to help move it and fix some of the dependencies. When considering using openemr, I considered the use of cvs as a bit of a downside, since making contributions back and keeping up with changes would mean using cvs. It is one of the things that has prevented me from contributing more back to the community.
I actually maintain a private repository with some private changes. I periodically bring over commits from cvs. Having the main repository in git would make it really easy for me to incorporate the public changes under my private ones by rebasing against the public repository. I happen to use mercurial privately, but I would immediately ditch that for git if that’s what were to run the main repository.
It would also make it easier for me to contribute some changes back, since I can keep them grouped by feature, and separated from the other changes that are useless to others. Then, I can rebase them back down to being against the public repository and ship off a changeset to the group.
I haven’t noticed any real dissent from the group, just a collection of hurdles that must be passed. Would starting a wiki page be a good way to keep track of the necessary steps to do before cutting over?
