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.
Comments?
-- Rod
www.sunsetsystems.com
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
Sam Bowen
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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 you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
Rod
www.sunsetsystems.com
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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)
-brady
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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?
-Andy
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Just to help with the discussion of pros/cons, here's a list of the main hurdles if change repository server or repos software:
-OpenEMR 3.1.0 CVS demo will break (fixable with time)
-OpenEMR 3.2.0 CVS demo will break (fixable with time)
-OpenEMR CVS demo will break (fixable with time)
-OpenEMR Developer Appliance (would need to release a new version, and then old version would be irreversibly broken)
-OpenEMR CVS ubuntu package will break (fixable with time and release of new version)
I'm still on the fence(I've just researched and test ran both svn and git). For me, I always just focus on the big picture (increasing the userbase), which will then obviously bring in the developers (some volunteers, such as myself, and some pros). Main things for this (I think) are an easy install, stable code, good support, and making it easy to demo/test the newest thing. I'd argue the above demos and tools help in keeping code stable, testing/demoing new features and also give users a way to begin to "learn" linux, how to modify codebase, and provide contributions. I'd argue removal of these tools would have a negative impact on the growing userbase (I may be biased, obviously, since I contributed all of these tools).
I just don't know if the grass is greener on the other side arguments really merit the potential loss of these tools and/or the time to fix them at this time. I definitely think as OpenEMR grows and more developers get involved, then a transition to git would seem appropriate, but just doesn't seem worth the work at this point. Our current development tools, demos, and strong support should help to capture newbie developers, and I'd argue that the pro developers should be adaptable (such as stephen-smith's strategy).
those are my current thought, which seem to change on a daily basis,
-brady
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
stephen-smith,
As an aside; can git download just a working copy from a remote repository from a specific branch? I'm asking this because having the cvs demos (and developer appliance) download the entire git openemr repository (getting close to 300MB) could be a bottleneck.
-brady
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Would it be possible to just move the tip (4.x) to git and leave the v3 repos and demos and appliances as is? That would mitigate the issue for the current 3.2 release and patches and allow us to move forward a bit. Earlier it was said that Git had cvsserver mode. That means, in theory, that the 4.0 appliance could stay the same for a while if SourceForge supports that option…
Tony
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Tony,
The server site is hard-coded into all these tools; so cvsserver mode wontt solve this because the server name would still change. Plus whats the point of recent cvs tip demo, appliance, and ubuntu cvs package if they are not grabbing most recent tip? If we go ahead with changing repos, then there is the potential to lose these tools indefinitely (just not sure when I'll have the time and nobody else has yet to build these tools); so will leave this decision up to the community.
-brady
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Tony,
To demonstrate the issue, here's the code:
# Download cvs version of openemr
if !(yes "" | cvs -d:pserver:anonymous:@openemr.cvs.sourceforge.net:/cvsroot/openemr login >> $LOG); then
# unable to connect to CVS to download OpenEMR
unable_exit "Unable to download OpenEMR cvs version from sourceforge"
exit 1
fi
output_both "Downloading OpenEMR cvs version from sourceforge (please be patient)"
if !(cvs -q -z3 -d:pserver:anonymous@openemr.cvs.sourceforge.net:/cvsroot/openemr co -P openemr >> $LOG); then
# unable to download OpenEMR
exit 1
fi
If sourceforge supports csvserver (for git), which is doubtful, I then wonder if we could replace the openemr directory in the csv repos with a symbolic link that directed to the git repository. Then perhaps the hard-coding in the demos/appliances will still work.
-brady
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
Comments?
-- Rod
www.sunsetsystems.com
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.
Sam Bowen
I'm willing to be a backup administrator and help with the planning and setup.
By the way there's a tool 'cvs2svn' that can convert the entire CVS repository to svn while retaining all the history of changes.
-- Rod
www.sunsetsystems.com
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,
Well I just tested anonymous CVS and it's working today. Plus I wouldn't want to switch without 100% support from everyone. Let's see how it goes.
-- Rod
www.sunsetsystems.com
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.
If SourceForge conversion to svn is imminent (ie 2-4 months) it seems reasonble to continue with cvs until then.
I am going to import the current cvs to svn at oemr.org to allow work on PHP5, MySQL5 etc.
Hey, looks like subversion is finally available on SourceForge:
https://sourceforge.net/project/admin/svn.php?group_id=60081
Any votes for a cutover date?
BTW I'll be away this weekend...
-- Rod
www.sunsetsystems.com
I personally would like to give them a month or two to make sure the kinks are really worked out.
Sam Bowen
I think Sam's idea's good,
lets wait couple of weeks for them to debug and then switch to SVN.
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.
Rod
www.sunsetsystems.com
hey,
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)
-brady
If the developer appliance issues were dealt with, I'm leaning towards git…(also looks very easy to convert a cvs repos to a git repos)
-brady
I'm beginning to persuade myself, maybe could fix the appliances near end of June. Here's a good comparison of repositories:
http://versioncontrolblog.com/comparison/Bazaar/CVS/Git/Mercurial/Subversion/index.html
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?
-Andy
hey,
Just to help with the discussion of pros/cons, here's a list of the main hurdles if change repository server or repos software:
-OpenEMR 3.1.0 CVS demo will break (fixable with time)
-OpenEMR 3.2.0 CVS demo will break (fixable with time)
-OpenEMR CVS demo will break (fixable with time)
-OpenEMR Developer Appliance (would need to release a new version, and then old version would be irreversibly broken)
-OpenEMR CVS ubuntu package will break (fixable with time and release of new version)
Here are links to cvs demos:
http://www.openmedsoftware.org/wiki/Main_Page#Development_Demos
Here is link to developer appliance:
http://www.openmedsoftware.org/wiki/OpenEMR_Developer_Virtual_Appliance
Here is link to cvs ubuntu package:
http://www.openmedsoftware.org/wiki/OpenEMR_Downloads#Ubuntu.2Fdebian_CVS_Version_Package
I'm still on the fence(I've just researched and test ran both svn and git). For me, I always just focus on the big picture (increasing the userbase), which will then obviously bring in the developers (some volunteers, such as myself, and some pros). Main things for this (I think) are an easy install, stable code, good support, and making it easy to demo/test the newest thing. I'd argue the above demos and tools help in keeping code stable, testing/demoing new features and also give users a way to begin to "learn" linux, how to modify codebase, and provide contributions. I'd argue removal of these tools would have a negative impact on the growing userbase (I may be biased, obviously, since I contributed all of these tools).
I just don't know if the grass is greener on the other side arguments really merit the potential loss of these tools and/or the time to fix them at this time. I definitely think as OpenEMR grows and more developers get involved, then a transition to git would seem appropriate, but just doesn't seem worth the work at this point. Our current development tools, demos, and strong support should help to capture newbie developers, and I'd argue that the pro developers should be adaptable (such as stephen-smith's strategy).
those are my current thought, which seem to change on a daily basis,
-brady
stephen-smith,
As an aside; can git download just a working copy from a remote repository from a specific branch? I'm asking this because having the cvs demos (and developer appliance) download the entire git openemr repository (getting close to 300MB) could be a bottleneck.
-brady
Would it be possible to just move the tip (4.x) to git and leave the v3 repos and demos and appliances as is? That would mitigate the issue for the current 3.2 release and patches and allow us to move forward a bit. Earlier it was said that Git had cvsserver mode. That means, in theory, that the 4.0 appliance could stay the same for a while if SourceForge supports that option…
Tony
Tony,
The server site is hard-coded into all these tools; so cvsserver mode wontt solve this because the server name would still change. Plus whats the point of recent cvs tip demo, appliance, and ubuntu cvs package if they are not grabbing most recent tip? If we go ahead with changing repos, then there is the potential to lose these tools indefinitely (just not sure when I'll have the time and nobody else has yet to build these tools); so will leave this decision up to the community.
-brady
Tony,
To demonstrate the issue, here's the code:
# Download cvs version of openemr
if !(yes "" | cvs -d:pserver:anonymous:@openemr.cvs.sourceforge.net:/cvsroot/openemr login >> $LOG); then
# unable to connect to CVS to download OpenEMR
unable_exit "Unable to download OpenEMR cvs version from sourceforge"
exit 1
fi
output_both "Downloading OpenEMR cvs version from sourceforge (please be patient)"
if !(cvs -q -z3 -d:pserver:anonymous@openemr.cvs.sourceforge.net:/cvsroot/openemr co -P openemr >> $LOG); then
# unable to download OpenEMR
exit 1
fi
Check out the git repos description page (note the paths to the repos will always differ, even if sourceforge supported cvsserver):
http://sourceforge.net/apps/trac/sourceforge/wiki/Git
If sourceforge supports csvserver (for git), which is doubtful, I then wonder if we could replace the openemr directory in the csv repos with a symbolic link that directed to the git repository. Then perhaps the hard-coding in the demos/appliances will still work.
-brady