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 >> > >
