I believe that everyone in the felix-users confluence group now has
access to edit pages in my 'personal space'.

On Tue, Dec 1, 2015 at 9:49 PM, Benson Margulies <bimargul...@gmail.com> wrote:
> 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
>>>>>>
>>>>>>
>>>>
>>

Reply via email to