On Tue, Dec 1, 2015 at 7:50 PM, David Jencks <david.a.jen...@gmail.com> wrote: > I also see no way to edit your page, and I have no idea who might be a > confluence space administrator who could change permissions. > > I was going to add to the pro-single-git-repo the point that you can check > out exactly the parts you want using git sparse-checkout. > > I don’t think the decision to move to git can be made independent of choice > of a git workflow. I’m strongly in favor of triangular workflow.
Presumably, when it's morning in Europe, someone will turn up who knows how to admin bimargul...@gmail.com into the Felix space. If not, I'll open an Infra ticket. meanwhile, can't you all at least put things into comments on the bottom? (I can't see a way to give other people edit permission to my 'personal space'). > > thanks > david jencks > >> On Dec 1, 2015, at 4:14 PM, 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. >> >>> >>> 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 >>>>> >>>>> >>> >
