On Wed, Feb 22, 2012 at 12:05 PM, Atif Aziz <[email protected]> wrote: > 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.
It's not a bit we can easily flip. Sorry. The read-only state is tied to the active version control system on your project. > > 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.
