llvm dev - Nov 2012 - [LLVMdev] Mailing List archive navigation (was Re: svn mirror git?)

> Side note (perhaps for another email thread)
fork'd
> Side note (perhaps for another email thread): am I missing something,
> or is the mailing list archive really that hard to link to the root of
> a thread & navigate the /whole/ thread over all time? Every time I go
> to the archive I find the fragment of a thread that occurred in a
> given month & I can't seem to find where to easily view/navigate
the
> whole thread across multiple months.
Yes, I find this extremely difficult as well.

I'm not sure exactly what all the components at play are for this, but
is it possible to plug in a new thread viewer? Or is there some
"mirror" somewhere in the net with easier navigation?

-- Sean Silva

On Thu, Nov 15, 2012 at 5:53 PM, David Blaikie <dblaikie at gmail.com>
wrote:
> On Thu, Nov 15, 2012 at 2:26 PM, Sean Silva <silvas at purdue.edu>
wrote:
>>> I'd suggest you/others read the previous thread discussing this
issue.
>>> It's a bit tricky to link to a whole thread in the llvm-dev
mail
>>> archive, but here's one part of it:
>>> http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-July/041738.html
>>
>> Maybe I should add this to the FAQ? Does this look good?:
>>
>> Why don't you move from svn to git?
>> =============================>>
>> Please read the following discussions about the issue, and think
>> carefully before bringing it up on the list:
>>
>> * http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-July/041738.html
>> * ... others ...
>
> Possible. I'm not sure it comes up quite often enough to draw
> attention to it in the FAQ (drawing attention to it might increase the
> number of conversations where someone thinks they've got some idea
> that we didn't cover last time), but maybe (& I'm not sure how
> many/which people read the FAQ anyway).
>
> Side note (perhaps for another email thread): am I missing something,
> or is the mailing list archive really that hard to link to the root of
> a thread & navigate the /whole/ thread over all time? Every time I go
> to the archive I find the fragment of a thread that occurred in a
> given month & I can't seem to find where to easily view/navigate
the
> whole thread across multiple months.
>
>>
>> -- Sean Silva
>>
>> On Thu, Nov 15, 2012 at 3:27 PM, David Blaikie <dblaikie at
gmail.com> wrote:
>>> On Thu, Nov 15, 2012 at 12:01 PM, Greg Fitzgerald <garious at
gmail.com> wrote:
>>>> Hi Michael,
>>>>
>>>>> As for actually switching to git. I see no benefit to
justify the cost
>>>>> of switching unless we actually take advantage of git's
features. And
>>>>> I've yet to see anyone propose this.
>>>>
>>>> Then I'll be the first.  :)
>>>
>>> I'd suggest you/others read the previous thread discussing this
issue.
>>> It's a bit tricky to link to a whole thread in the llvm-dev
mail
>>> archive, but here's one part of it:
>>> http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-July/041738.html
>>>
>>>> The benefit is that the review process would require no file
copies or email
>>>> attachments, shorter email conversations, no copying code
during reviews to
>>>> simulate inline comments, and no need to "git rebase"
to push to the top of
>>>> svn.  I wouldn't be surprised if the difference was so
significant that
>>>> folks would stop using the llvm-commits list altogether.  To
see what
>>>> changed, you'd check the github mirror, and to contribute
you could post a
>>>> link to llvmdev (not too noisy).
>>>
>>> Essentially that's precisely what we want to avoid. The
intention is
>>> to keep discussion & review in the shared public view &
keep the
>>> codebase in a (mostly) singular state. The transition to git would
>>> have to be justified on its merits while still preserving that
>>> workflow, not while working against it.
>>>
>>> (I'm not sure how folks would stop using llvm-commits all
together, if
>>> we still have as much shared development there would still be a
push
>>> email for every shared commit, an email for every review request,
and
>>> if the reduction in email was because review happened off-list,
that
>>> would be a loss, not a benefit)
>>>
>>>> For example, say github's llvm-mirror was a
contributor's fork.  The review
>>>> process might look like this:
>>>>
>>>> Contributor:
>>>>      Please review my patch:
>>>>
https://github.com/llvm-mirror/llvm/commit/4823be3be1d87632fbd51ce8e51a58ee5e44b115
>>>>
>>>> Maintainer:
>>>>     Adds inline comments with online tool.  Then when patch is
looking good:
>>>>     $ git fetch https://github.com/llvm-mirror/llvm.git
>>>>     $ git cherry-pick 4823be3be1d87632fbd51ce8e51a58ee5e44b115
>>>>     $ git push
>>>>
>>>> Thanks,
>>>> Greg
>>>>
>>>>
>>>> On Thu, Nov 15, 2012 at 11:35 AM, Michael Spencer
<bigcheesegs at gmail.com>
>>>> wrote:
>>>>>
>>>>> On Thu, Nov 15, 2012 at 10:48 AM, David Chisnall
>>>>> <David.Chisnall at cl.cam.ac.uk> wrote:
>>>>> >> > I think svn works better than git as an
authoritative upstream
>>>>> >>
>>>>> >> Would you mind expanding on this?  What problem
specifically is being
>>>>> >> solved?  Linus and Guido both use DVCS's and
the authoritative upstream is
>>>>> >> whatever URL the BDFL says it is.
>>>>> >
>>>>> > Monotonic version numbers are the biggest advantage. 
It is easy to see
>>>>> > that r1234432 contains the bug fix introduced in
r1234430. It is very hard
>>>>> > to see if version 23bef194ac contains the bug fix
added in 23bef19412.  This
>>>>> > makes interaction with bugzilla and so on much easier.
If someone says
>>>>> > 'please test r1245145 - should be fixed' you
can easily check whether you
>>>>> > are running r1245145 or newer.
>>>>> >
>>>>> > David
>>>>>
>>>>> git branch --contains 23bef19412
>>>>>
>>>>> This will tell you which of your branches have that commit
and
>>>>> highlight the current branch you are on.
>>>>>
>>>>> Git also has monotonically increasing identifiers for each
commit. The
>>>>> time stamp. Which I find much more informative than a
revision number
>>>>> split between multiple repositories.
>>>>>
>>>>> As for actually switching to git. I see no benefit to
justify the cost
>>>>> of switching unless we actually take advantage of git's
features. And
>>>>> I've yet to see anyone propose this. So for now,
git-svn works for me.
>>>>>
>>>>> - Michael Spencer
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> LLVM Developers mailing list
>>>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>>>
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev