Re: Making github.com/apache/sling a git repo, moving away old svn mirror (Re: apache/sling as github landing repository)

2018-02-28 Thread Alexander Klimetschek
On 27.02.2018, at 22:07, Robert Munteanu wrote: > IIUC the proposal was to import the old svn mirror as a git repo, and > Betrand argued this would be a really large repo, and that's an > impediment for something which would be heavily cloned. You are right. It could be two

Re: Making github.com/apache/sling a git repo, moving away old svn mirror (Re: apache/sling as github landing repository)

2018-02-27 Thread Robert Munteanu
On Thu, 2018-02-15 at 20:57 +, Alexander Klimetschek wrote: > On 12.02.2018, at 01:23, Robert Munteanu wrote: > > The basic proposal as I see it would be to add a new 'sling' top- > > level > > github repo, which means that: > > > > 1. we control what goes in there -

Re: Making github.com/apache/sling a git repo, moving away old svn mirror (Re: apache/sling as github landing repository)

2018-02-15 Thread Alexander Klimetschek
On 12.02.2018, at 01:23, Robert Munteanu wrote: > The basic proposal as I see it would be to add a new 'sling' top-level > github repo, which means that: > > 1. we control what goes in there - README.md most importantly > 2. old links to sling commits and files will be broken

Re: Making github.com/apache/sling a git repo, moving away old svn mirror (Re: apache/sling as github landing repository)

2018-02-12 Thread Bertrand Delacretaz
On Mon, Feb 12, 2018 at 10:23 AM, Robert Munteanu wrote: > ...The basic proposal as I see it would be to add a new 'sling' top-level > github repo, which means that: > > 1. we control what goes in there - README.md most importantly > 2. old links to sling commits and files

Making github.com/apache/sling a git repo, moving away old svn mirror (Re: apache/sling as github landing repository)

2018-02-12 Thread Robert Munteanu
Hi, I usually am reluctant in revisiting old decisions, especially ones that were so discussed, like this one. Some summaries of previous discussion are at [1], [2] . But Alex makes some good points and after the migration I think we should consider whether backwards compatibility of incoming