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 >
