Hi All, Git-svn is a nice workaround for the developer. As a user you don't want to be installing from version control in any case. Version control is a means for tracking changes, not for distributing software. Let the CI system protect you from needless drama.
Typed with thumbs. > On Sep 5, 2014, at 5:03 PM, "Ryan C. Thompson" <r...@thompsonclan.org> wrote: > > Hi all, > > Just to throw in a suggestion here, I know that many people use a tool like > git-svn in this kind of situation. They want the ability to make multiple > small commits in order to save their progress, but they don't want those > commits visible until they are ready to push all at once. This allows one to > make breaking changes in one commit that are fixed by subsequent commits, > because the intermediate states will never be exposed. > > For information on git-svn, see here: > http://git-scm.com/book/en/Git-and-Other-Systems-Git-and-Subversion > > Note that I don't personally have any experience with svn or with git-svn, > but this seems like exactly the use case for it. > > -Ryan > >> On Fri 05 Sep 2014 04:50:49 PM PDT, Peter Haverty wrote: >> Hi all, >> >> I respectfully disagree. One should certainly check in each discrete unit >> of work. These will often not result in something that is ready to be used >> by someone else. Bumping the version number constitutes a new release and >> carries the implicit promise that the package works again. This is why >> continuous integration systems do a build when the version number changes. >> >> One should expect working software when installing a pre-build package (the >> tests passed, right?). Checking out from SVN is for developers of that >> package and nothing should be assumed about the current state of the code. >> >> To keep everyone happy, one could add a commit hook to our SVN setup that >> would add the SVN revision number to the version string. This would be for >> dev only and hopefully not sufficient to trigger a build. >> >> That's my two cents. Happy weekend all. >> >> Regards, >> >> >> >> Pete >> >> ____________________ >> Peter M. Haverty, Ph.D. >> Genentech, Inc. >> phave...@gene.com >> >> >>> On Fri, Sep 5, 2014 at 4:30 PM, Dan Tenenbaum <dtene...@fhcrc.org> wrote: >>> >>> >>> >>> ----- Original Message ----- >>>> From: "Stephanie M. Gogarten" <sdmor...@u.washington.edu> >>>> To: "Dan Tenenbaum" <dtene...@fhcrc.org>, "bioc-devel" < >>> bioc-devel@r-project.org> >>>> Sent: Friday, September 5, 2014 4:27:13 PM >>>> Subject: Re: [Bioc-devel] Please bump version number when committing >>> changes >>>> >>>> I am guilty of doing this today, but I have (I think) a good reason. >>>> I'm making a bunch of changes that are all related to each other, but >>>> are being implemented and tested in stages. I'd like to use svn to >>>> commit when I've made a set of changes that works, so I can roll back >>>> if >>>> I break something in the next step, but I'd like the users to see >>>> them >>>> all at once as a single version update. Perhaps others are doing >>>> something similar? >>> >>> I understand the motivation but this still results in an ambiguous state >>> if two different people check out your package from svn at different times >>> today (before and after your changes). >>> >>> Version numbers are cheap, so if version 1.2.3 exists for a day before >>> version 1.2.4 (which contains all the changes you want to push to your >>> users) then that's ok, IMO. >>> >>> Including a version bump doesn't impact whether or not you can rollback a >>> commit with svn. >>> >>> Dan >>> >>> >>> >>>> Stephanie >>>> >>>>> On 9/4/14, 12:04 PM, Dan Tenenbaum wrote: >>>>> Hello, >>>>> >>>>> Looking through our svn logs, I see that there are many commits >>>>> that are not accompanied by version bumps. >>>>> All svn commits (or, if you are using the git-svn bridge, every >>>>> group of commits included in a push) should include a version bump >>>>> (that is, incrementing the "z" segment of the x.y.z version >>>>> number). This practice is documented at >>>>> http://www.bioconductor.org/developers/how-to/version-numbering/ . >>>>> >>>>> Failure to bump the version has two consequences: >>>>> >>>>> 1) Your changes will not propagate to our package repository or web >>>>> site, so users installing your package via biocLite() will not >>>>> receive the latest changes unless you bump the version. >>>>> >>>>> 2) Users *can* always get the current files of your package using >>>>> Subversion, but if you've made changes without bumping the version >>>>> number, it can be difficult to troubleshoot problems. If two >>>>> people are looking at what appears to be the same version of a >>>>> package, but it's behaving differently, it can be really >>>>> frustrating to realize that the packages actually differ (but not >>>>> by version number). >>>>> >>>>> So if you're not already, please get in the habit of bumping the >>>>> version number with each set of changes you commit. >>>>> >>>>> Let us know on bioc-devel if you have any questions about this. >>>>> >>>>> Thanks, >>>>> Dan >>>>> >>>>> _______________________________________________ >>>>> Bioc-devel@r-project.org mailing list >>>>> https://stat.ethz.ch/mailman/listinfo/bioc-devel >>> >>> _______________________________________________ >>> Bioc-devel@r-project.org mailing list >>> https://stat.ethz.ch/mailman/listinfo/bioc-devel >> >> [[alternative HTML version deleted]] >> >> _______________________________________________ >> Bioc-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/bioc-devel _______________________________________________ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
