You can continue using SF for release. On Thu, Aug 18, 2011 at 3:14 AM, Julian Maughan <[email protected]>wrote:
> 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 >>>> >>> >>> >> > -- Fabio Maulo
