> On Dec 1, 2015, at 19:14, Benson Margulies <bimargul...@gmail.com> wrote: > > On Dec 1, 2015 6:43 PM, "Richard S. Hall" <he...@ungoverned.org> wrote: >> >> >>> On Dec 1, 2015, at 17:50, Benson Margulies <bimargul...@gmail.com> > wrote: >>> >>> > https://cwiki.apache.org/confluence/display/~bimargul...@gmail.com/Felix+and+Git >>> >>> ? >> >> Seems like a good start, although is that editable by others? > > I don't know. Try? I don't have perms to make a page on the Felix wiki , if > I get some I will move it.
Well, I sort of did try, which is why I was asking. Perhaps I didn’t see the “edit” button. Regardless, I’m the wrong person to try to lead this debate anyway, since I don’t enjoy SCM if the first place… :-) -> richard > >> >> It seems like other technical issues were raised about the approaches, so > it would be nice to see those added in there by people who have experience. >> >> I admit, for me, SCM is a necessary evil and not something I get too > exited about. I haven’t seen anything to prefer git over svn or vice versa. > They’re just different hammers for the same nail. >> >> Still, thinking about the options, it seems like multiple repos creates a > maintenance headache to some degree. For example, line-ending handling is > fairly difficult to get configured correctly in git. By having multiple > repositories, then every repository would have to have this configured > individually, since stuff like that is good to have configured uniformly. > Any changes to how we want things uniformly handled would require manual > propagation of configuration. Of course, this seems like it would be an > issue in any proliferation of repositories (svn or git). >> >> Or perhaps there is a better way to handle such issues? >> >> -> richard >> >>> >>> >>> On Tue, Dec 1, 2015 at 1:56 PM, Richard S. Hall <he...@ungoverned.org> > wrote: >>>> On 12/1/15 13:40 , Carsten Ziegeler wrote: >>>>> >>>>> Richard S. Hall wrote >>>>>> >>>>>> Well, the argument to the contrary is perhaps that is makes it more >>>>>> difficult for us as a community to have oversight into releases. It >>>>>> almost assures us that some/many community members will never > checkout >>>>>> subprojects that aren't in the repository they normally work. > Granted, >>>>>> there is no guarantee of this now, since I can just check out what I >>>>>> want anyway...but at least it is fairly easy for me to do so now and > it >>>>>> becomes more difficult if everyone spreads to their own repos. >>>>>> >>>>>> So, in that regard, I'm more aligned with Marcel...all or nothing > makes >>>>>> more sense. >>>>> >>>>> Hmm, ok fair point - however, the *all* is the problematic part where > we >>>>> couldn't agree on last time (one git repo vs many git repos). >>>> >>>> >>>> But isn't it then incumbent on those wanting such changes to convince > us one >>>> way or the other? >>>> >>>> Personally, I'd rather just have one big git repo if we are going to > switch, >>>> if for no other reason than it seems like less overhead. However, I > admit to >>>> not really knowing the advantages/disadvantages. >>>> >>>> Regardless, at a minimum, perhaps someone should create a documented >>>> pros/cons list for the approaches. This would at least give us a way > to call >>>> a vote where we can feel somewhat informed about the choices (i.e., > stay >>>> with svn, move to one git repo, move to many git repos). >>>> >>>> Better than saying, "there is no consensus, so let's just go our > separate >>>> ways"... >>>> >>>> -> richard >>>> >>>> >>>>> >>>>> We could still provide a script in the root of svn which checks out > the >>>>> moved projects from git and gives the same experience :) >>>>> >>>>> Carsten >>>> >>>> >>
