Does anybody have any thoughts on where to publish the next NH release (or releases after 3.2.1)? I agree with keeping the SVN repository on SF for a while, but if we are generally moving away from SF, perhaps releases should be hosted elsewhere. One option is NHForge - but I don't know if this is stable/scalable enough, or if it provides download stats. GitHub doesn't seem to provide a place for releases (?)
On 18 August 2011 05:14, Stephen Bohlen <[email protected]> wrote: > Also thinking about this from the POV of the fact that the existing SVN > repo URL is widely-known/posted/linked-to/etc. With this kind of an > approach, anyone blindly doing an svn update would get the new file and > (hopefully!) notice it in their working copy... > > > Steve Bohlen > [email protected] > http://blog.unhandled-exceptions.com > http://twitter.com/sbohlen > > > On Wed, Aug 17, 2011 at 5:11 PM, Stephen Bohlen <[email protected]>wrote: > >> Since the existing SVN repo is effectively read-only for everyone but the >> small group of committers, my guess is that we're "safe" just ensuring that >> the existing committers are told "hands off the SVN repo for the foreseeable >> future" but I'm also thinking of how someone new to NH would know that the >> SVN repo was obsolete (and this not to use it as the basis for creating >> patches, etc.). >> >> What about committing a text file into the root of the SVN repo named >> THIS_REPOSITORY_IS_OBSOLETE___DO_NOT_USE___READ_ME_FOR_DETAILS.txt that >> explains the location of the new github repo so that there's at least some >> way of new folks not making the mistake of working with this repo any >> longer? >> >> >> Steve Bohlen >> [email protected] >> http://blog.unhandled-exceptions.com >> http://twitter.com/sbohlen >> >> >> On Wed, Aug 17, 2011 at 5:02 PM, Patrick Earl <[email protected]> wrote: >> >>> On Wed, Aug 17, 2011 at 1:26 PM, Stephen Bohlen <[email protected]> >>> wrote: >>> > I think that there are probably several housekeeping issues that still >>> > remain to be addressed around this process: >>> > >>> > We need to decide what to do about the disposition of the existing SVN >>> repo >>> > (shut it down completely, annotate its content as SUPERSEDED and direct >>> ppl >>> > to the git repo via a readme note in it, etc., etc.). What are >>> people's >>> > ideas about how best to handle this? Is it the case at this point that >>> the >>> > entire contents of the SVN repo are in git (e.g., there have been no >>> > subsequent commits to the SVN repo since the import to git)? >>> >>> There have been no new commits and all branches and tags have been >>> imported to the best of my knowledge. 6004 was the last SVN commit >>> included. There have been a couple commits on the GIT repository >>> after the import. >>> >>> I believe we should start directing people to the new repository, and >>> if possible change the existing one to read-only. I don't think we >>> should delete it until more time has passed. >>> >>> We should decide on our suggested workflow for issues / pull requests >>> / feature branches. The castle project folks might be able to provide >>> some insight here, since they went though a similar situation. >>> >>> > We need to decide how to handle the existing SVN-based patches that >>> have >>> > been attached to still-open JIRA issues. Properly applying these to >>> TRUNK >>> > as the contents of the SVN and git repos diverge over time is probably >>> going >>> > to be a non-trivial process (unless someone has some pearls of wisdom >>> to >>> > share re: tricks for handling this simply...I've never actually tried >>> to >>> > apply an SVN patch to a non-SVN-controlled set of files...is this even >>> > possible???) >>> >>> The SVN patches are almost just unified diffs. These can be applied >>> without much effort using generic patch tools. >>> >>> For example: >>> http://stackoverflow.com/questions/659467/how-to-apply-svn-diff-to-git >>> >>> The patches in JIRA tend to be small or require significant >>> modification anyways, so I don't think this will be a major issue in >>> practice. >>> >>> Patrick Earl >>> >> >> >
