On 06.07.2011 19:08, Greg Stein wrote: > On Tue, Jul 5, 2011 at 16:04, Rob Weir <apa...@robweir.com> wrote: >> On Tue, Jul 5, 2011 at 3:33 PM, Mathias Bauer <mathias_ba...@gmx.net> wrote: >>> Moin, >>> >>> On 05.07.2011 18:14, Mathias Bauer wrote: >>... >>> Do we really want to have code in the svn repo that will never be used? >>> The alternative would be to add cws to svn only after review. > > Having code in the repository is fine. It is better to have it there > and not need it, then to need it and not have it there. > > As people have stated, these extra CWSs do not add that much more > space. And Apache has more than enough disk space. It is not a > concern. > >> Right. That is why I was thinking that maybe we just create an >> archival copy of the entire repository, including all CWS, and host >> that as a read only Hg or git instance. Then migrate the trunk to >> SVN, If there are some CWS that we know are already approved for >> 3.4, then include those as well. > > Apache only has one repository: Subversion. > > The read-only Git instance is simply a mirror of the canonical > Subversion repository. > >> That way, if someone does come by, months later, and decide they want >> to complete work CWS, then they can still clone them and work on them. >> But then they would need to copy them into a SVN working copy, and >> merge and commit from there. Obviously, this does complicate things >> for the future CWS developers. But they are in the best position to >> stabilize and merge their work. > > Haven't we already gone through the whole discussion about CWSs that > may rename files, and that we want to do that rename within Hg before > converting to Subversion? > > Let's not mess around with multiple repositories. That is just making > it difficult for us. How is somebody supposed to investigate a CWS > when it lives in a separate repository? That is just making it harder > for ourselves. Yes, you are right. The idea with moving all cws into svn and then work from there is good enough and trying to make things better is a waste of time that could even backfire.
So sorry for the noise, let's proceed with the hg->svn migration. Regards, Mathias
