llvm dev - Nov 2012 - [LLVMdev] svn mirror git?

On 15 Nov 2012, at 10:40, Greg Fitzgerald wrote:
> Do you mean in the same way that clock skew would affect Make?  Or just
that Ninja doesn't provide that nice "clock skew detected" message
that Make does?  Or are you looking for a build system that uses file hashes
instead of last-modified times?
Ninja complains about circular dependencies when you have your clock set to the
wrong time.  There is no easy way of fixing this other than to delete the entire
build tree and start again.
> > 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

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

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.  :)

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).

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20121115/f404b205/attachment.html>