I'm sure no one enjoys bumps, but would appreciate a response and hopefully an exception here:
At this point, we need to make a service release for an issue troubling > many users. I'm hoping you can flip some switch to turn our SVN repo > read-write. Would that be possible? I can imagine creating another GCPH project where the SVN repo can be re-imported but it feels like an additional project maintenance headache at this point, especially if the read-only status is just a bit than be easily flipped by GCPH admins. Thanks, Atif On Sat, Feb 18, 2012 at 2:22 PM, Atif Aziz <[email protected]> wrote: > I understand and perhaps that's a reasonable default but the history > between these source control systems doesn't translate perfectly and the > effort to even recreate the branch-merge history of a project with moderate > complexity. I decided to use the top-skimming apporach since we were going > ahead with a major release where we could affort have breaking changes. At > this point, we need to make a service release for an issue troubling many > users. I'm hoping you can flip some switch to turn our SVN repo > read-write. Would that be possible? > > BTW, I don't think projects would change repos without communicating to > team members so the chances of committing to the non-canonical repo are > very slim. > - Atif > > On Fri, Feb 17, 2012 at 8:59 PM, Augie Fackler <[email protected]> wrote: > >> On Tue, Feb 14, 2012 at 4:41 PM, Atif Aziz <[email protected]> wrote: >> > According to the ConvertingSvnToHg wiki on GCPH support: >> > >> > "Your old Subversion project will still be accessible after you switch >> > your project to using Mercurial, …" >> > >> > I understood "accessible" to mean pretty much functional as far as >> > source control goes. A few months back, I moved just the trunk of the >> > ELMAH project (http://elmah.googlecode.com) over to Hg. Porting the >> > entire history with full fidelity was proving to be difficult and not >> > worth the overall effort. I figured that if the time came to make a >> > quick fix to one of the older release branches then it could be just >> > applied to the SVN repo and a service release issued. That time came >> > and I learned the hard way that commits to the SVN repo were no longer >> > possible. I was wondering if this can be enabled for my project. Is >> > there any technical reason not to allow the non-default SVN repo to be >> > fully functional, at least for the project owner? >> >> The thinking (AIUI, I wasn't part of the team then) was that once you >> move your system of record for version control, that's it, you're >> done. In general, I've found that to be true, and having the >> non-canonical system be readonly is generally valuable so people don't >> miss the conversion and try to commit to a dead repository. >> >> > >> > Thanks, >> > Atif >> > >> > -- >> > You received this message because you are subscribed to the Google >> Groups "Project Hosting on Google Code" group. >> > To post to this group, send email to >> [email protected]. >> > To unsubscribe from this group, send email to >> [email protected]. >> > For more options, visit this group at >> http://groups.google.com/group/google-code-hosting?hl=en. >> > >> > > -- You received this message because you are subscribed to the Google Groups "Project Hosting on Google Code" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-code-hosting?hl=en.
