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
