Re: [webkit-dev] Moving to Git

2019-02-21 Thread Simon Fraser
> On Feb 21, 2019, at 12:18 AM, Bug Tracker 
>  wrote:
> 
> Thank you all very much for your help! I really appreciate it. :-)
> 
> P.S.: I decided to start learning git-svn.

https://trac.webkit.org/wiki/UsingGitWithWebKit 
 has the information you need.

Simon

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Moving to Git

2019-02-21 Thread Bug Tracker
Thank you all very much for your help! I really appreciate it. :-)

P.S.: I decided to start learning git-svn.



‐‐‐ Original Message ‐‐‐
On Wednesday, February 20, 2019 11:48 PM, Adrian Perez de Castro 
 wrote:

> On Wed, 20 Feb 2019 22:30:22 +0300, Konstantin Tokarev annu...@yandex.ru 
> wrote:
>
> > 20.02.2019, 22:27, "Bug Tracker" bug.tracking.acco...@protonmail.com:
> >
> > > Sorry, for the anonymous email. I opted for it because the list archives 
> > > are public and concluded that it's not that useful to reveal my identity 
> > > for the purposes of this question.
> > > In short, however, I am a graduate student interested in using WebKit for 
> > > an academic project and thought that I should ask first about the 
> > > progress on Git migration, since it would be far easier for me to work 
> > > with WebKit then.
> >
> > You can use public Git mirror:
> > https://github.com/WebKit/webkit
>
> You can even do upstream WebKit development using exclusively Git, even
> without needing to use the GitHub mirror, see:
>
> https://trac.webkit.org/wiki/UsingGitWithWebKit#Checkout
>
> Even for things which would normally require Subversion, “git svn” can be
> used 99.9% of the time. For the usual “pull latest code from master, make
> a branch, prepare a patch, upload patch to Bugzilla for landing” Subversion
> is not needed at all. Just make sure you have 20 to 30 GiB of space for the
> Git checkout and building WebKit.
>
> For other more specialized workflows, like checking out release branches and
> version tags you will need some “git svn” usage; but IMO that is still nicer
> than having to use Subversion.
>
> I hope this helps!
>
> -Adrián


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Moving to Git

2019-02-20 Thread Adrian Perez de Castro
On Wed, 20 Feb 2019 22:30:22 +0300, Konstantin Tokarev  
wrote:
 
> 20.02.2019, 22:27, "Bug Tracker" :
>
> > Sorry, for the anonymous email. I opted for it because the list archives 
> > are public and concluded that it's not that useful to reveal my identity 
> > for the purposes of this question.
> >
> > In short, however, I am a graduate student interested in using WebKit for 
> > an academic project and thought that I should ask first about the progress 
> > on Git migration, since it would be far easier for me to work with WebKit 
> > then.
> 
> You can use public Git mirror:
> 
> https://github.com/WebKit/webkit

You can even do upstream WebKit development using exclusively Git, even
without needing to use the GitHub mirror, see:

  https://trac.webkit.org/wiki/UsingGitWithWebKit#Checkout

Even for things which would normally require Subversion, “git svn” can be
used 99.9% of the time. For the usual “pull latest code from master, make
a branch, prepare a patch, upload patch to Bugzilla for landing” Subversion
is not needed at all. Just make sure you have 20 to 30 GiB of space for the
Git checkout and building WebKit.

For other more specialized workflows, like checking out release branches and
version tags you will need some “git svn” usage; but IMO that is still nicer
than having to use Subversion.

I hope this helps!


-Adrián


pgpE6Sz_YtHI3.pgp
Description: PGP signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Moving to Git

2019-02-20 Thread Maciej Stachowiak


> On Feb 20, 2019, at 12:14 PM, Michael Catanzaro  wrote:
> 
> FWIW, it's not hard to enforce fast-forward merges with a git hook; that way, 
> we can guarantee that the history has no merge commits and is fully linear. 
> GitLab has built-in support to enforce this for merge requests (though not 
> for direct commits). I agree that linear history is a must for a project the 
> size of WebKit. rNN tags would be nice, but hardly essential as long as 
> the history is linear.

I think our concern is not just linearity. The reason Ryosuke suggests 
monotonically increasing revisions is because we often need to answer questions 
like the following:

- This performance graph shows a regression between revision A and revision B, 
I wonder how many revisions are between those?
- I need to manually bisect a regression between revisions X and Y. I wonder 
what the approximate midpoint is?

Monotonically increasing sequential numbers make it super easy to answer 
questions like that. Ideally, such revision numbers would also be accepted by 
all tools we have to work with. Many git revision number solutions I have seen 
involve running an extra tool or consulting an additional website to be able to 
make determinations like this, and that would be a significant task on 
performance regression defense in particular.

We’d love to hear about solutions that can provide something like this, ideally 
ones that are GitHub compatible.

> 
> On Wed, Feb 20, 2019 at 1:38 PM, Bug Tracker 
>  wrote:
>> I considered this option, but my work will involve touching multiple parts 
>> of the codebase and thus I would like to be able to keep up / merge locally 
>> with the upstream every now and then (e.g. on each relatively stable 
>> release, such as Apple's Safari Technology Preview).
>> However, all branches, tags etc. are available only on SVN.
> 
> Migrating to git would be wonderful, but a huge amount of infrastructure 
> effort. Since it's unlikely that anyone is going to invest the large amount 
> of effort required to transition WebKit to git anytime soon, I'd recommend 
> learning how to work with git-svn. It's a bit of effort but not too hard, and 
> way better than using Subversion directly.
> 
> Michael
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Moving to Git

2019-02-20 Thread Michael Catanzaro
FWIW, it's not hard to enforce fast-forward merges with a git hook; 
that way, we can guarantee that the history has no merge commits and is 
fully linear. GitLab has built-in support to enforce this for merge 
requests (though not for direct commits). I agree that linear history 
is a must for a project the size of WebKit. rNN tags would be nice, 
but hardly essential as long as the history is linear.


On Wed, Feb 20, 2019 at 1:38 PM, Bug Tracker 
 wrote:
I considered this option, but my work will involve touching multiple 
parts of the codebase and thus I would like to be able to keep up / 
merge locally with the upstream every now and then (e.g. on each 
relatively stable release, such as Apple's Safari Technology Preview).


However, all branches, tags etc. are available only on SVN.


Migrating to git would be wonderful, but a huge amount of 
infrastructure effort. Since it's unlikely that anyone is going to 
invest the large amount of effort required to transition WebKit to git 
anytime soon, I'd recommend learning how to work with git-svn. It's a 
bit of effort but not too hard, and way better than using Subversion 
directly.


Michael

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Moving to Git

2019-02-20 Thread Bug Tracker
I considered this option, but my work will involve touching multiple parts of 
the codebase and thus I would like to be able to keep up / merge locally with 
the upstream every now and then (e.g. on each relatively stable release, such 
as Apple's Safari Technology Preview).

However, all branches, tags etc. are available only on SVN.


‐‐‐ Original Message ‐‐‐
On Wednesday, February 20, 2019 9:30 PM, Konstantin Tokarev  
wrote:

> 20.02.2019, 22:27, "Bug Tracker"bug.tracking.acco...@protonmail.com:
>
> > Sorry, for the anonymous email. I opted for it because the list archives 
> > are public and concluded that it's not that useful to reveal my identity 
> > for the purposes of this question.
> > In short, however, I am a graduate student interested in using WebKit for 
> > an academic project and thought that I should ask first about the progress 
> > on Git migration, since it would be far easier for me to work with WebKit 
> > then.
>
> You can use public Git mirror:
>
> https://github.com/WebKit/webkit
>
> > ‐‐‐ Original Message ‐‐‐
> > On Wednesday, February 20, 2019 8:34 PM, Simon Fraser 
> > simon.fra...@apple.com wrote:
> >
> > > Are you a WebKit developer? I can't tell from your email.
> > > Simon
> > >
> > > > On Feb 20, 2019, at 8:27 AM, Bug Tracker 
> > > > bug.tracking.acco...@protonmail.com wrote:
> > > > Hi,
> > > > I was curious about the status of the proposal for migrating from SVN 
> > > > to Git (https://trac.webkit.org/wiki/Moving to Git).
> > > > The relevant page on the Trac wiki hasn't been updated for over 5 years 
> > > > and since then Git has become much more popular (the de facto standard 
> > > > for new projects, more or less), while:
> > > >
> > > > -   SVN support is diminishing (e.g. in Xcode).
> > > > -   Git support on Windows is much better than 5 years ago.
> > > > -   It's difficult to find free robust SVN clients / UIs, unlike the 
> > > > plethora of options available for Git.
> > > > -   Most young and relatively new developers (with less than 10 years 
> > > > of experience, like myself) are much more comfortable with Git and 
> > > > maybe have not even used SVN before, so moving to Git could encourage 
> > > > more users and contributors.
> > > >
> > > > Is there any progress in this direction?
> > > > Thank you, in advance!
> > > >
> > > > webkit-dev mailing list
> > > > webkit-dev@lists.webkit.org
> > > > https://lists.webkit.org/mailman/listinfo/webkit-dev
> >
> > ,
> >
> > webkit-dev mailing list
> > webkit-dev@lists.webkit.org
> > https://lists.webkit.org/mailman/listinfo/webkit-dev
>
> -- 
> Regards,
> Konstantin


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Moving to Git

2019-02-20 Thread Konstantin Tokarev


20.02.2019, 22:27, "Bug Tracker" :
> Sorry, for the anonymous email. I opted for it because the list archives are 
> public and concluded that it's not that useful to reveal my identity for the 
> purposes of this question.
>
> In short, however, I am a graduate student interested in using WebKit for an 
> academic project and thought that I should ask first about the progress on 
> Git migration, since it would be far easier for me to work with WebKit then.

You can use public Git mirror:

https://github.com/WebKit/webkit

>
> ‐‐‐ Original Message ‐‐‐
> On Wednesday, February 20, 2019 8:34 PM, Simon Fraser 
>  wrote:
>
>> Are you a WebKit developer? I can't tell from your email.
>>
>> Simon
>>
>>> On Feb 20, 2019, at 8:27 AM, Bug Tracker 
>>>  wrote:
>>>
>>> Hi,
>>>
>>> I was curious about the status of the proposal for migrating from SVN to 
>>> Git (https://trac.webkit.org/wiki/Moving%20to%20Git).
>>>
>>> The relevant page on the Trac wiki hasn't been updated for over 5 years and 
>>> since then Git has become much more popular (the de facto standard for new 
>>> projects, more or less), while:
>>>
>>> * SVN support is diminishing (e.g. in Xcode).
>>> * Git support on Windows is much better than 5 years ago.
>>> * It's difficult to find free robust SVN clients / UIs, unlike the plethora 
>>> of options available for Git.
>>> * Most young and relatively new developers (with less than 10 years of 
>>> experience, like myself) are much more comfortable with Git and maybe have 
>>> not even used SVN before, so moving to Git could encourage more users and 
>>> contributors.
>>>
>>> Is there any progress in this direction?
>>>
>>> Thank you, in advance!
>>> ___
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org
>>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
> ,
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev


-- 
Regards,
Konstantin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Moving to Git

2019-02-20 Thread Bug Tracker
Sorry, for the anonymous email. I opted for it because the list archives are 
public and concluded that it's not that useful to reveal my identity for the 
purposes of this question.

In short, however, I am a graduate student interested in using WebKit for an 
academic project and thought that I should ask first about the progress on Git 
migration, since it would be far easier for me to work with WebKit then.

‐‐‐ Original Message ‐‐‐
On Wednesday, February 20, 2019 8:34 PM, Simon Fraser  
wrote:

> Are you a WebKit developer? I can't tell from your email.
>
> Simon
>
>> On Feb 20, 2019, at 8:27 AM, Bug Tracker 
>>  wrote:
>>
>> Hi,
>>
>> I was curious about the status of the proposal for migrating from SVN to Git 
>> (https://trac.webkit.org/wiki/Moving%20to%20Git).
>>
>> The relevant page on the Trac wiki hasn't been updated for over 5 years and 
>> since then Git has become much more popular (the de facto standard for new 
>> projects, more or less), while:
>>
>> - SVN support is diminishing (e.g. in Xcode).
>>
>> - Git support on Windows is much better than 5 years ago.
>>
>> - It's difficult to find free robust SVN clients / UIs, unlike the plethora 
>> of options available for Git.
>>
>> - Most young and relatively new developers (with less than 10 years of 
>> experience, like myself) are much more comfortable with Git and maybe have 
>> not even used SVN before, so moving to Git could encourage more users and 
>> contributors.
>>
>> Is there any progress in this direction?
>>
>> Thank you, in advance!
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Moving to Git

2019-02-20 Thread Simon Fraser
Are you a WebKit developer? I can't tell from your email.

Simon

> On Feb 20, 2019, at 8:27 AM, Bug Tracker 
>  wrote:
> 
> Hi,
> 
> I was curious about the status of the proposal for migrating from SVN to Git 
> (https://trac.webkit.org/wiki/Moving%20to%20Git 
> ).
> 
> The relevant page on the Trac wiki hasn't been updated for over 5 years and 
> since then Git has become much more popular (the de facto standard for new 
> projects, more or less), while:
> SVN support is diminishing (e.g. in Xcode).
> Git support on Windows is much better than 5 years ago.
> It's difficult to find free robust SVN clients / UIs, unlike the plethora of 
> options available for Git.
> Most young and relatively new developers (with less than 10 years of 
> experience, like myself) are much more comfortable with Git and maybe have 
> not even used SVN before, so moving to Git could encourage more users and 
> contributors.
> 
> Is there any progress in this direction?
> 
> Thank you, in advance!
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Moving to Git

2019-02-20 Thread Ryosuke Niwa
On Wed, Feb 20, 2019 at 10:02 AM Philippe Normand  wrote:

> On Wed, 2019-02-20 at 09:40 -0800, Ryosuke Niwa wrote:
> >
> > On Wed, Feb 20, 2019 at 8:28 AM Bug Tracker <
> > bug.tracking.acco...@protonmail.com> wrote:
> > > I was curious about the status of the proposal for migrating from
> > > SVN to Git (https://trac.webkit.org/wiki/Moving%20to%20Git).
> > >
> > > The relevant page on the Trac wiki hasn't been updated for over 5
> > > years and since then Git has become much more popular (the de facto
> > > standard for new projects, more or less), while:
> > > SVN support is diminishing (e.g. in Xcode).
> > > Git support on Windows is much better than 5 years ago.
> > > It's difficult to find free robust SVN clients / UIs, unlike the
> > > plethora of options available for Git.
> > > Most young and relatively new developers (with less than 10 years
> > > of experience, like myself) are much more comfortable with Git and
> > > maybe have not even used SVN before, so moving to Git could
> > > encourage more users and contributors.
> > >
> > > Is there any progress in this direction?
> > >
> >
> > No progress has been made as far as I can tell. Every other year or
> > so, this topic comes up on webkit-dev, and the outcome is always the
> > same.
> >
> > We need a monotonically increasing revision number to track down perf
> > regressions, etc... yet nobody has put the time & effort to create a
> > solution with Git.
>
> Quoting the wiki page linked above:
>
> Some previously svn projects have worked around this. For example,
> Haiku uses automatic linear tags on each push.
> http://cgit.haiku-os.org/haiku/log/


Right, I'm totally aware of that solution because it has come up in the
past. Chromium implemented a similar solution (presumably
Cr-Commit-Position is that thing?).

What we need is a concrete plan to add the support for such a mechanism in
WebKit and update all the tools we have: buildbot, webkitpy, etc...

As far as I can tell, nobody has yet to propose such a plan for WebKit.
THAT is the biggest blocker as far as I can tell.

- R. Niwa
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Moving to Git

2019-02-20 Thread Philippe Normand
On Wed, 2019-02-20 at 09:40 -0800, Ryosuke Niwa wrote:
> 
> On Wed, Feb 20, 2019 at 8:28 AM Bug Tracker <
> bug.tracking.acco...@protonmail.com> wrote:
> > I was curious about the status of the proposal for migrating from
> > SVN to Git (https://trac.webkit.org/wiki/Moving%20to%20Git).
> > 
> > The relevant page on the Trac wiki hasn't been updated for over 5
> > years and since then Git has become much more popular (the de facto
> > standard for new projects, more or less), while:
> > SVN support is diminishing (e.g. in Xcode).
> > Git support on Windows is much better than 5 years ago.
> > It's difficult to find free robust SVN clients / UIs, unlike the
> > plethora of options available for Git.
> > Most young and relatively new developers (with less than 10 years
> > of experience, like myself) are much more comfortable with Git and
> > maybe have not even used SVN before, so moving to Git could
> > encourage more users and contributors.
> > 
> > Is there any progress in this direction?
> > 
> 
> No progress has been made as far as I can tell. Every other year or
> so, this topic comes up on webkit-dev, and the outcome is always the
> same.
> 
> We need a monotonically increasing revision number to track down perf
> regressions, etc... yet nobody has put the time & effort to create a
> solution with Git. 

Quoting the wiki page linked above:

Some previously svn projects have worked around this. For example,
Haiku uses automatic linear tags on each push. 
http://cgit.haiku-os.org/haiku/log/

Philippe

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Moving to Git

2019-02-20 Thread Ryosuke Niwa
On Wed, Feb 20, 2019 at 8:28 AM Bug Tracker <
bug.tracking.acco...@protonmail.com> wrote:

>
> I was curious about the status of the proposal for migrating from SVN to
> Git (https://trac.webkit.org/wiki/Moving%20to%20Git).
>
> The relevant page on the Trac wiki hasn't been updated for over 5 years
> and since then Git has become much more popular (the de facto standard for
> new projects, more or less), while:
>
>1. SVN support is diminishing (e.g. in Xcode).
>2. Git support on Windows is much better than 5 years ago.
>3. It's difficult to find free robust SVN clients / UIs, unlike the
>plethora of options available for Git.
>4. Most young and relatively new developers (with less than 10 years
>of experience, like myself) are much more comfortable with Git and maybe
>have not even used SVN before, so moving to Git could encourage more users
>and contributors.
>
>
> Is there any progress in this direction?
>

No progress has been made as far as I can tell. Every other year or so,
this topic comes up on webkit-dev, and the outcome is always the same.

We need a monotonically increasing revision number to track down perf
regressions, etc... yet nobody has put the time & effort to create a
solution with Git. I stay firmly opposed to making the Subversion-to-Git
transition until such a solution is devised and implemented in various
tools we use.

And no, we can't use git-bisect because performance tests take anywhere
from 30min to an hour, and we may need ~8 runs to detect a statistically
significant difference of 1% or less, meaning that even deciding whether a
given perf regression exists between revision X and Y might take ~8 hours.

I'm increasingly frustrated that people keep bringing this topic up without
ever resolving the issues that have been raised in the past. Keep bringing
up the same topic without presenting a solution to the problems that have
been raised in the past 8 years or so of the discussion is simply
unproductive.

- R. Niwa
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Moving to Git

2019-02-20 Thread Bug Tracker
Hi,

I was curious about the status of the proposal for migrating from SVN to Git 
(https://trac.webkit.org/wiki/Moving%20to%20Git).

The relevant page on the Trac wiki hasn't been updated for over 5 years and 
since then Git has become much more popular (the de facto standard for new 
projects, more or less), while:

- SVN support is diminishing (e.g. in Xcode).

- Git support on Windows is much better than 5 years ago.

- It's difficult to find free robust SVN clients / UIs, unlike the plethora of 
options available for Git.

- Most young and relatively new developers (with less than 10 years of 
experience, like myself) are much more comfortable with Git and maybe have not 
even used SVN before, so moving to Git could encourage more users and 
contributors.

Is there any progress in this direction?

Thank you, in advance!
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Moving to Git?

2012-03-11 Thread Ryosuke Niwa
On Fri, Mar 9, 2012 at 6:35 PM, Pablo Flouret pab...@motorola.com wrote:

 I'd prefer to see something closer to what 'git format-patch' spits out.
 Basically you give it a commit range and it spits out one diff per commit,
 including the commit message.


That seems to imply we're completely changing the semantics and the format
of change logs. I'd rather not get into such a discussion on this thread,
and I think that's a much more controversial change.

So you'd have a patch that includes commit messages ready for reviewers'
 perusal (which i presume is the biggest reason changelogs still exist?)


Please go through the webkit-dev archive before in the past 3 years :)

In my most frequent workflow i make a patch, submit it, make a local commit
 in git for myself (in a branch) and then move on to other things (in a
 different branch perhaps). Then when review comments come in, i address
 them, make a local commit with those changes, and upload a patch by giving
 a range to webkit-patch. ChangeLog files are a pain in the ass in this
 case. Also, reviewers don't get to see what changed between the two patches
 i uploaded, which a patch coming from format-patch would show.


Being able to see changes between two patches will be a very valuable tool.
I always open two review pages side-by-side to see what has changed in new
patch. However, such a review tool can be implemented on Bugzilla without
moving to git.

In fact, the diff's between two local git commits is of little use for me
as a reviewer because what I want to see is the diff between the latest
patch and the last patch I looked at.

- Ryosuke
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Moving to Git?

2012-03-11 Thread Ashod Nakashian

 From: Ryosuke Niwa rn...@webkit.org
To: Pablo Flouret pab...@motorola.com 
Cc: webkit-dev@lists.webkit.org 
Sent: Sunday, March 11, 2012 12:01 PM
Subject: Re: [webkit-dev] Moving to Git?
 

On Fri, Mar 9, 2012 at 6:35 PM, Pablo Flouret pab...@motorola.com wrote:
I'd prefer to see something closer to what 'git format-patch' spits out.
Basically you give it a commit range and it spits out one diff per commit, 
including the commit message.



That seems to imply we're completely changing the semantics and the format of 
change logs. I'd rather not get into such a discussion on this thread, and I 
think that's a much more controversial change.


So you'd have a patch that includes commit messages ready for reviewers' 
perusal (which i presume is the biggest reason changelogs still exist?)



Please go through the webkit-dev archive before in the past 3 years :)


In my most frequent workflow i make a patch, submit it, make a local commit in 
git for myself (in a branch) and then move on to other things (in a different 
branch perhaps). Then when review comments come in, i address them, make a 
local commit with those changes, and upload a patch by giving a range to 
webkit-patch. ChangeLog files are a pain in the ass in this case. Also, 
reviewers don't get to see what changed between the two patches i uploaded, 
which a patch coming from format-patch would show.


Being able to see changes between two patches will be a very valuable tool. I 
always open two review pages side-by-side to see what has changed in new 
patch. However, such a review tool can be implemented on Bugzilla without 
moving to git.


In fact, the diff's between two local git commits is of little use for me as a 
reviewer because what I want to see is the diff between the latest patch and 
the last patch I looked at.

There certainly are review tools that do exactly that. ReviewBoard[1] is one 
such that I'm thoroughly familiar with. It has a solid API that can be used in 
a very similar way to how we're uploading patches on bugzilla, automated mail 
notifications etc. and can be integrated with bugzilla/build-servers with 
reasonable effort. In addition, it shows all patches uploaded with diff between 
any two, which is what a reviewer is mostly interested in: to see what changed 
between patches and if her issues were addressed properly or not.

I totally agree that these are completely independent of the VCS and can 
(should?) be utilized where appropriate independent of the topic at hand.

[1] http://www.reviewboard.org/



- Ryosuke


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev



___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Moving to Git?

2012-03-10 Thread Gavin Barraclough
On Mar 9, 2012, at 12:30 PM, Mark Rowe wrote:

 What you'll find is that the vast majority of SVN users are simply not 
 participating in this email thread. You'll also find that many people that 
 use git-svn are happy enough with the status quo since it gives those who 
 chose to use it most of the benefits of a pure Git setup without forcing it 
 on others.
 
 In my opinion a substantial benefit needs to be demonstrated in order to 
 convince the existing SVN users, many of which are substantial long-term 
 contributors to the project, that it's worth it to them to relearn how to 
 contribute to WebKit. And I do feel that SVN users need to want to switch to 
 Git in order for it to be worth pursuing such a switch. As a heavy Git user 
 myself I've not seen any arguments in this thread that would be convincing to 
 someone not already familiar with Git.

I think Mark makes a couple of very good points here.

As an svn user, I'm under no illusion about the fact that git is clearly a more 
powerful tool, and that it's important that we support git access for 
contributors who need it.  However I find that personally I work much more 
efficiently in svn – my needs are modest and I find git overly complex for my 
very simple requirements.  I would be happy to give greater consideration to 
moving to git if it would significantly benefit either me or the project as a 
whole for me to do so.

Reading through this thread, it's not obvious to me that accommodating both svn 
and git users is a huge burden on the project.  I hope this is the case, 
because I have to say, the status quo seems pretty good (which isn't to say 
there aren't ways we could improve our processes – there are a few good 
suggestions in this thread).  It seems beneficial to the project to accommodate 
the needs of a wide range of contributors as well as we reasonable can, and it 
seems that we are in a fortunate position with regard to version control where 
we are already doing so very well.  I would hope this would only change if 
there were good reason to do so.

cheers,
G.

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Moving to Git?

2012-03-10 Thread Joe Mason
Well, the more git-idiomatic usage is to git commit your work in progress 
often, in particular before updating. This wouldn't touch Node.h at all, it 
just upates the index (in the .git hidden subdir).  Then the rebase also 
wouldn't touch Node.h, unless there were changes to it upstream.

 I just recommended the stash/update/pop sequence because it more closely 
matched the SVN workflow which you like, and I'm trying to figure out how hard 
it would be to support this workflow with git.  I hadn't thought about the 
issue of extra file touches, though - good catch.

Here's a better alternative:

git commit -a -c temp commit  git pull --rebase origin/master
(fix any conflicts and finish the rebase with git rebase --continue if 
necessary)
git reset HEAD^

Instead of using the stash, that puts all your working copy changes into a 
commit, fetches, and then gets rid of the commit (leaving the changes still in 
the working copy).  There might be some weirdness if there are new 
files/subdirs instead of just changes to existing files - I'd need to check how 
that gets handled and possibly tweak some commandline parameters.

From: webkit-dev-boun...@lists.webkit.org [webkit-dev-boun...@lists.webkit.org] 
on behalf of Ryosuke Niwa [rn...@webkit.org]
Sent: Friday, March 09, 2012 7:01 PM
To: Ashod Nakashian
Cc: WebKit Development
Subject: Re: [webkit-dev] Moving to Git?

First, a follow up on my old post since my message was cut off in the middle:
On Thu, Mar 8, 2012 at 1:25 PM, Ryosuke Niwa 
rn...@webkit.orgmailto:rn...@webkit.org wrote:
On Thu, Mar 8, 2012 at 1:19 PM, Joe Mason 
jma...@rim.commailto:jma...@rim.com wrote:
This is only slightly more complicated

I'd say astoundingly more complicated because of

the fact that you're unapplying changes, updating the checkout, and reapplying 
changes. This seemingly innocent sequence of operations have an annoying 
side-effects of touching all files you've modified locally and haven't 
committed.

So for example if you have any changes to Node.h and run this set of 
operations, then git will touch Node.h twice by stashing and applying. This 
would mean that I would be rebuilding the world even if all changes I get from 
masters were in webkitpy or LayoutTests.

Are there an easy way to work around this issue as well? (other than committing 
changes, of course)

On Fri, Mar 9, 2012 at 3:54 PM, Ashod Nakashian 
ashodnakash...@yahoo.commailto:ashodnakash...@yahoo.com wrote:
After all, what prompted me to raise this issue is because some svn scripts are 
outdated and before fixing them I thought may be there wasn't much use for them 
in the first place (otherwise, someone with a bigger contribution volume would 
certainly have noticed and fixed them sooner than me).

I suspect the only reason the particular bug hadn't been fixed is that we have 
very few contributors who develop on Windows.

- Ryosuke


-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Moving to Git?

2012-03-10 Thread Maciej Stachowiak

I think one factor that makes many people stick with SVN is that emulating the 
SVN-style workflow in Git is pretty complicated. Let's consider a typical SVN 
user's process:

1) Develop one patch at a time.
2) During development, often update his sources to match the repository.
3) When done, create a patch and get it reviewed.
4) When the patch is reviewed, commit it.

The interaction with the version-control system for each of these steps is an 
obvious single step with SVN. With git, for at least some of these, you will 
end up needing multiple non-obvious (to an SVN user anyway) commands. All of 
your examples below for step 2 are complicated and have surprising side effects.

The usual responses to this concern are either you can write a script to wrap 
that or you should just change your workflow to get the full power of git. 
But neither of these answers is very persuasive to a person happy with the 
above workflow. When we had to do the CVS to SVN transition, there was no 
hesitation because everyone could still use the exact same workflow, but now it 
was also possible to do more stuff.

I do think that with the right project-wide scripts we could abstract away from 
the VCS a little and make the transition less painful. I do most of my patch 
creation and committing with webkit-patch(*) these days, because it actually 
saves steps over the raw tools. However, update-webkit, which handles the 
remaining SVN-like workflow step, doesn't follow any of the approaches, instead 
it does this:

sub runGitUpdate()
{
# Doing a git fetch first allows setups with svn-remote.svn.fetch = 
trunk:refs/remotes/origin/master
# to perform the rebase much much faster.
system(git, fetch) == 0 or die;
if (isGitSVN()) {
system(git, svn, rebase) == 0 or die;
} else {
# This will die if branch.$BRANCHNAME.merge isn't set, which is
# almost certainly what we want.
system(git, pull) == 0 or die;
}
}

Perhaps improving runGitUpdate() would be one way to make it easier for more 
people to try Git.

Regards,
Maciej

(*) I'm not sure offhand if webkit-patch land will take care of all three of 
the steps of adding, committing and pushing/dcommiting which the SVN-like 
workflow treats as a single step.


On Mar 10, 2012, at 2:58 PM, Joe Mason wrote:

 Well, the more git-idiomatic usage is to git commit your work in progress 
 often, in particular before updating. This wouldn't touch Node.h at all, it 
 just upates the index (in the .git hidden subdir).  Then the rebase also 
 wouldn't touch Node.h, unless there were changes to it upstream.
 
 I just recommended the stash/update/pop sequence because it more closely 
 matched the SVN workflow which you like, and I'm trying to figure out how 
 hard it would be to support this workflow with git.  I hadn't thought about 
 the issue of extra file touches, though - good catch.
 
 Here's a better alternative:
 
 git commit -a -c temp commit  git pull --rebase origin/master
 (fix any conflicts and finish the rebase with git rebase --continue if 
 necessary)
 git reset HEAD^
 
 Instead of using the stash, that puts all your working copy changes into a 
 commit, fetches, and then gets rid of the commit (leaving the changes still 
 in the working copy).  There might be some weirdness if there are new 
 files/subdirs instead of just changes to existing files - I'd need to check 
 how that gets handled and possibly tweak some commandline parameters.
 
 From: webkit-dev-boun...@lists.webkit.org 
 [webkit-dev-boun...@lists.webkit.org] on behalf of Ryosuke Niwa 
 [rn...@webkit.org]
 Sent: Friday, March 09, 2012 7:01 PM
 To: Ashod Nakashian
 Cc: WebKit Development
 Subject: Re: [webkit-dev] Moving to Git?
 
 First, a follow up on my old post since my message was cut off in the middle:
 On Thu, Mar 8, 2012 at 1:25 PM, Ryosuke Niwa 
 rn...@webkit.orgmailto:rn...@webkit.org wrote:
 On Thu, Mar 8, 2012 at 1:19 PM, Joe Mason 
 jma...@rim.commailto:jma...@rim.com wrote:
 This is only slightly more complicated
 
 I'd say astoundingly more complicated because of
 
 the fact that you're unapplying changes, updating the checkout, and 
 reapplying changes. This seemingly innocent sequence of operations have an 
 annoying side-effects of touching all files you've modified locally and 
 haven't committed.
 
 So for example if you have any changes to Node.h and run this set of 
 operations, then git will touch Node.h twice by stashing and applying. This 
 would mean that I would be rebuilding the world even if all changes I get 
 from masters were in webkitpy or LayoutTests.
 
 Are there an easy way to work around this issue as well? (other than 
 committing changes, of course)
 
 On Fri, Mar 9, 2012 at 3:54 PM, Ashod Nakashian 
 ashodnakash...@yahoo.commailto:ashodnakash...@yahoo.com wrote:
 After all, what prompted me to raise this issue is because some svn scripts 
 are outdated and before fixing them I thought may

Re: [webkit-dev] Moving to Git?

2012-03-10 Thread Kalle Vahlman
2012/3/11 Maciej Stachowiak m...@apple.com:

 The interaction with the version-control system for each of these steps is an 
 obvious single step with SVN. With git, for at least some of these, you will 
 end up needing multiple non-obvious (to an SVN user anyway) commands.

I understand the context of this argument and it is of course valid
but it gets REALLY boring to hear this every time someone tries to
make a point :)

I've used svn long time ago and git ever since. For me it's no longer
obvious that my local changes are not safe from merging if I do an
update. It is also not obvious that I could not simply commit my patch
(locally) and continue on to the next one when the changes are
touching the same files etc.

The 'obvious' argument should IMO be avoided at all times, because it
inherently carries the notion that the svn way is somehow the de facto
way of doing things in everybody's minds. It is not. It is always
subjective what workflow makes sense.

-- 
Kalle Vahlman, z...@iki.fi
Powered by http://movial.com
Interesting stuff at http://sandbox.movial.com
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Moving to Git?

2012-03-10 Thread Maciej Stachowiak

On Mar 10, 2012, at 9:55 PM, Kalle Vahlman wrote:

 2012/3/11 Maciej Stachowiak m...@apple.com:
 
 The interaction with the version-control system for each of these steps is 
 an obvious single step with SVN. With git, for at least some of these, you 
 will end up needing multiple non-obvious (to an SVN user anyway) commands.
 
 I understand the context of this argument and it is of course valid
 but it gets REALLY boring to hear this every time someone tries to
 make a point :)
 
 I've used svn long time ago and git ever since. For me it's no longer
 obvious that my local changes are not safe from merging if I do an
 update. It is also not obvious that I could not simply commit my patch
 (locally) and continue on to the next one when the changes are
 touching the same files etc.
 
 The 'obvious' argument should IMO be avoided at all times, because it
 inherently carries the notion that the svn way is somehow the de facto
 way of doing things in everybody's minds. It is not. It is always
 subjective what workflow makes sense.

I think we largely agree here. Some people find the SVN workflow subjectively 
makes sense to them. Others find that the Git workflow subjectively makes sense 
to them. They are different enough that not everyone finds it natural to 
switch. Conveniently, we support both.

Regards,
Maciej
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Moving to Git?

2012-03-09 Thread Tor Arne Vestbø

On 09.03.12 01:36, Aaron Boodman wrote:

I think it would look the same, except for instead of monotonically
increasing decimal numbers in the revision column, you'd see random
hexadecimal ones (typically 6-8 digits long).


It would be possible to use 'git describe' [1] to give something like this:

  r-110272-g19c9e9c7

If we tag the initial commit in the repository as 'r'. The number refers 
to the number of commits after the tag 'r'.


We could optionally tag WebKit versions, and get something like:

  v525.19-12345-g19c9e9c7

Meaning 12345 commits after v525.19 was tagged. Doing the latter does 
not prevent the former, as you can use --match r to force the initial tag.


tor arne

[1] http://linux.die.net/man/1/git-describe



On Thu, Mar 8, 2012 at 4:20 PM, Lucas Forschlerlforsch...@apple.com  wrote:

Could someone enlighten me on what this page would look like after a conversion 
to git?

http://build.webkit.org/builders/Windows%20Debug%20%28Build%29?numbuilds=100

Lucas

On Mar 8, 2012, at 3:22 PM, Dirk Pranke wrote:


On Thu, Mar 8, 2012 at 2:37 PM, David Barrdavidb...@google.com  wrote:

The monotonic labels that Ryosuke desires are known in git language as
generation numbers. If we maintain a canonical linear history going
forward, they would also be unique as with Subversion. This could be a
good reason to resurrect the relevant thread on the git mailing list.



slightly-offtopic, but I had not heard of generation numbers before.
Based on a cursory web-learning pass (*), it sounds like they're not
quite the same thing as SVN revisions, since SVN revision numers are
unique to a repo, and two revisions on two different branches may have
the same generation number. Since we do actually keep branches in the
master repo, this wouldn't quite be the same  (although it might
possibly be acceptable). Please correct me if I'm wrong ...

-- Dirk

(*) http://stackoverflow.com/questions/6702821/git-commit-generation-numbers
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Moving to Git?

2012-03-09 Thread Tor Arne Vestbø

On 08.03.12 22:25, Ryosuke Niwa wrote:

That'll certainly be an improvement. I still dislike git hashes though.
If someone implements such a script in webkit-patch and we can
automatically assign svn-revision like numbers to all commits, I can be
convinced to use git.


Dunno about webkit-patch, but would make sense to roll into update-webkit.

Regarding revision numbers, 'git describe' could help us give a common 
way to describe revisions with monotonically increasing revision numbers.


tor arne
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Moving to Git?

2012-03-09 Thread Konstantin Tokarev


08.03.2012, 21:35, Alexis Menard alexis.men...@openbossa.org:
 On Thu, Mar 8, 2012 at 2:32 PM, Konrad Piascik kpias...@rim.com wrote:

  It is possible to keep linear history with git.  This just requires you to 
 fast forward and rebase before pushing.

 But can you enforce in the server? To avoid people to push it by mistake?

You can use Gerrit [1] to enforce linear history.

[1] http://code.google.com/p/gerrit/

-- 
Regards,
Konstantin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Moving to Git?

2012-03-09 Thread Adam Treat
With svn up you are just as likely to see a conflict.

From: ryosuke.n...@gmail.com [ryosuke.n...@gmail.com] on behalf of Ryosuke Niwa 
[rn...@webkit.org]
Sent: Thursday, March 08, 2012 3:12 PM
To: Adam Treat
Cc: Ashod Nakashian; WebKit Development
Subject: Re: [webkit-dev] Moving to Git?

On Thu, Mar 8, 2012 at 12:04 PM, Adam Treat 
atr...@rim.commailto:atr...@rim.com wrote:
There is nothing about git that forces you to have multiple branches locally.  
Good practice, yes, but nothing forcing it.  As for the difficulty of resolving 
conflicts between patches you've made locally and changes made on the shared 
repository since you started making your local patches... nothing about git 
makes this any harder.  Unless you have a lock based source control system 
you'll have to resolve conflicts.

On Thu, Mar 8, 2012 at 12:05 PM, Joe Mason 
jma...@rim.commailto:jma...@rim.com wrote:
It seems to me that there's no need to use multiple local branches in git if 
you find it confusing - it's an additional feature, but I don't see anything 
that requires it.

What workflow do you have that requires you to have multiple branches locally 
in git, and how do you solve it in svn without using branches?

What precisely do you find difficult about merging remote changes, and how is 
the svn equivalent easier?

The simplicity. In git, I have to worry about things like committing local 
changes before rebasing to master, or stashing, etc... In svn, all I have to do 
is to run svn up.

- Ryosuke


-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Moving to Git?

2012-03-09 Thread Konstantin Tokarev


09.03.2012, 18:24, Adam Treat atr...@rim.com:
 With svn up you are just as likely to see a conflict.

And in case of doubtful conflicts you won't be able to revert you tree to it's 
previous state so easily as with git.

-- 
Regards,
Konstantin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Moving to Git?

2012-03-09 Thread Ashod Nakashian

 From: David Barr davidb...@google.com
To: Ryosuke Niwa rn...@webkit.org 
Cc: webkit-dev@lists.webkit.org webkit-dev@lists.webkit.org 
Sent: Friday, March 9, 2012 2:37 AM
Subject: Re: [webkit-dev] Moving to Git?
 

I think we ought to streamline the git workflow before we start trying
to proselytise Subversion users. :)



Can you be more specific? What do you find wanting in the git workflow besides 
the few cases raised by svn users (such as svn up that can be supported in 
update-webkit)?

I think if we address the main issues raised by the svn users, the current 
consensus (if representative) seems to point towards an overwhelming support 
(and demand?) for git over svn. On that point it's reasonable to say that we're 
heading towards option #1 or #2 of Maciej. As such, I'm humbly proposing the 
following (hopefully without getting ahead of myself):

A) Address as many of the issues raised by the svn users and streamline their 
use-cases in the current scripts on top of git that we can (this would leave 
generation numbers out of scope as it's a git issue, although we can push that 
on git's mail-list). Address any current issues that (advanced/seasoned) git 
users find wanting/missing to have a solid system that capitalizes on the 
powers of git as much as possible.

B) Plan a phase-out schedule for svn repo, servers and scripts and mainlining 
git (this needs input from ops and those who can assess the overhead involved - 
something I'm ignorant of). Offer the option of having svn mirror (however 
realistic that is, I can't tell) keeping in mind the overhead of maintaining 
the svn scripts.

If we don't do anything we'll be supporting both systems, scripts, docs etc. 
with little advantage but having the choice of both systems (status-quo). If we 
start moving towards git I think we'll end up with the reverse situation than 
what we have now (git mainline, svn mirror) and, assuming the majority use git 
and there are more benefits to git over svn, then WebKit will benefit more that 
way than the case is now. However, having said that, something tells me the 
remaining svn users will probably switch to git sooner rather than later.

(Disclaimer: I enjoy svn as much as the next guy, but I think git offers enough 
power to justify the overhead of learning/adapting/migrating to it. In 
addition, as many pointed out, no one has to use all the power features and the 
svn-equivalent day-to-day ones can be automated transparently by current (and 
new) scripts.)

-Ash

The monotonic labels that Ryosuke desires are known in git language as
generation numbers. If we maintain a canonical linear history going
forward, they would also be unique as with Subversion. This could be a
good reason to resurrect the relevant thread on the git mailing list.

--
David Barr.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev



___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Moving to Git?

2012-03-09 Thread Ryosuke Niwa
On Fri, Mar 9, 2012 at 7:14 AM, Ashod Nakashian ashodnakash...@yahoo.comwrote:

 Can you be more specific? What do you find wanting in the git workflow
 besides the few cases raised by svn users (such as svn up that can be
 supported in update-webkit)?


I'm also annoyed by now git diff works since I almost always want git diff
master as I said in another thread. There are a number of other things I
don't like about git. Also, I think I'd prefer mercurial over git for its
saner behavior and terminologies if we're switching to a different VCS but
I'm not about to start a thread for that.

Quite frankly, moving to git will make my workflow worse regardless of
improvements... It's like forcing me to use Linux instead of Windows/Mac.
I'll do it if the overwhelming majority of the community thinks that's a
good thing but I won't be happy about it.

I think if we address the main issues raised by the svn users, the current
 consensus (if representative) seems to point towards an overwhelming
 support (and demand?) for git over svn. On that point it's reasonable to
 say that we're heading towards option #1 or #2 of Maciej. As such, I'm
 humbly proposing the following (hopefully without getting ahead of myself):


Frankly, I don't quite understand the benefit of this transition. Do we
really need to move to git? If the only problem of keeping svn was about
svn-apply being broken, I'm more than happy to fix that script.

A) Address as many of the issues raised by the svn users and streamline
 their use-cases in the current scripts on top of git that we can (this
 would leave generation numbers out of scope as it's a git issue, although
 we can push that on git's mail-list). Address any current issues that
 (advanced/seasoned) git users find wanting/missing to have a solid system
 that capitalizes on the powers of git as much as possible.


I'd argue that generation numbers is a requirement for this transition.
Monotonically increasing number is one major benefit of using svn server.
Also, ideally, this generation number will be consisnte with the existing
svn revision numbers so that if N is the last revision committed to the svn
repository then the first commit in the git repository should have the
generation number of N+1.

- Ryosuke
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Moving to Git?

2012-03-09 Thread Konrad Piascik
Hi Ryosuke,

There are solutions in git for all of your raised issues.  If you want to have 
git diff work against master then you just need to setup an alias to do that 
for you.
http://gitready.com/intermediate/2009/02/06/helpful-command-aliases.html

This way you can create aliases for all the commands and syntax you want.

Alexis mentioned that it is possible to have a linear history that Qt uses.  It 
should also be possible to setup a git hook on the server side to modify the 
commit message and include the revision number.

-Konrad

From: webkit-dev-boun...@lists.webkit.org [webkit-dev-boun...@lists.webkit.org] 
on behalf of Ryosuke Niwa [rn...@webkit.org]
Sent: Friday, March 09, 2012 11:33 AM
To: Ashod Nakashian
Cc: webkit-dev@lists.webkit.org
Subject: Re: [webkit-dev] Moving to Git?

On Fri, Mar 9, 2012 at 7:14 AM, Ashod Nakashian 
ashodnakash...@yahoo.commailto:ashodnakash...@yahoo.com wrote:
Can you be more specific? What do you find wanting in the git workflow besides 
the few cases raised by svn users (such as svn up that can be supported in 
update-webkit)?

I'm also annoyed by now git diff works since I almost always want git diff 
master as I said in another thread. There are a number of other things I don't 
like about git. Also, I think I'd prefer mercurial over git for its saner 
behavior and terminologies if we're switching to a different VCS but I'm not 
about to start a thread for that.

Quite frankly, moving to git will make my workflow worse regardless of 
improvements... It's like forcing me to use Linux instead of Windows/Mac. I'll 
do it if the overwhelming majority of the community thinks that's a good thing 
but I won't be happy about it.

I think if we address the main issues raised by the svn users, the current 
consensus (if representative) seems to point towards an overwhelming support 
(and demand?) for git over svn. On that point it's reasonable to say that we're 
heading towards option #1 or #2 of Maciej. As such, I'm humbly proposing the 
following (hopefully without getting ahead of myself):

Frankly, I don't quite understand the benefit of this transition. Do we really 
need to move to git? If the only problem of keeping svn was about svn-apply 
being broken, I'm more than happy to fix that script.

A) Address as many of the issues raised by the svn users and streamline their 
use-cases in the current scripts on top of git that we can (this would leave 
generation numbers out of scope as it's a git issue, although we can push that 
on git's mail-list). Address any current issues that (advanced/seasoned) git 
users find wanting/missing to have a solid system that capitalizes on the 
powers of git as much as possible.

I'd argue that generation numbers is a requirement for this transition. 
Monotonically increasing number is one major benefit of using svn server. Also, 
ideally, this generation number will be consisnte with the existing svn 
revision numbers so that if N is the last revision committed to the svn 
repository then the first commit in the git repository should have the 
generation number of N+1.

- Ryosuke

-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Moving to Git?

2012-03-09 Thread Kalle Vahlman
2012/3/9 Ryosuke Niwa rn...@webkit.org:
 On Fri, Mar 9, 2012 at 7:14 AM, Ashod Nakashian ashodnakash...@yahoo.com
 wrote:
 I think if we address the main issues raised by the svn users, the current
 consensus (if representative) seems to point towards an overwhelming support
 (and demand?) for git over svn. On that point it's reasonable to say that
 we're heading towards option #1 or #2 of Maciej. As such, I'm humbly
 proposing the following (hopefully without getting ahead of myself):


 Frankly, I don't quite understand the benefit of this transition. Do we
 really need to move to git? If the only problem of keeping svn was about
 svn-apply being broken, I'm more than happy to fix that script.

I think you missed the part where the impact on servers was discussed.
If every time someone does svn log the server needs to not receive
or deal out commits, it will show in response times. I'm sure people
using svn do not check the log often, for obvious reasons, but it is
still a factor to consider.

-- 
Kalle Vahlman, z...@iki.fi
Powered by http://movial.com
Interesting stuff at http://sandbox.movial.com
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Moving to Git?

2012-03-09 Thread Gustavo Noronha Silva
On Fri, 2012-03-09 at 08:33 -0800, Ryosuke Niwa wrote:

 Frankly, I don't quite understand the benefit of this transition. Do
 we really need to move to git? If the only problem of keeping svn was
 about svn-apply being broken, I'm more than happy to fix that script.

For me the biggest benefit would be to do away with ChangeLog files, if
we come to that by moving to git. I'm otherwise happy with using the git
mirror and git svn for all my needs.

Cheers,


-- 
Gustavo Noronha Silva g...@gnome.org
GNOME Project

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Moving to Git?

2012-03-09 Thread Gustavo Noronha Silva
On Thu, 2012-03-08 at 19:39 -0300, Alexis Menard wrote:
  To svn user :
  - Conflict resolving much easier and performant than svn (we have
  drivers for changelogs and the default one are much better than svn).
  - Local history/blaming/...
  - Proper diff coloration (though I'm sure you guys have some magic
  scripts using colordiff).
  - The staging area, upload what you want/need and keep some work local
  - Smaller checkouts
 
 - Bot maintainers :
 Power outage or network interruption in the middle of a svn
 checkout/up lock the repo sometimes and you need to manually svn
 cleanup the checkout (maybe someone have a tool or script to avoid
 that???). I had much more svn locked repos than git dead checkout
 because of interruptions.

/me puts his bot maintainer hat on

That does suck indeed. Been a while since I had to manually intervene,
but even when it is fixed automatically, the new checkout takes ages
(because the automatic fix is to rm -rf the whole source tree).

That said, we don't need to change the main repository to have bots use
git - we can use a git mirror for most bot needs without changing the
main repository.

Cheers,

-- 
Gustavo Noronha Silva g...@gnome.org
GNOME Project

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Moving to Git?

2012-03-09 Thread Mark Rowe

On 2012-03-09, at 10:23, Gustavo Noronha Silva g...@gnome.org wrote:

 On Thu, 2012-03-08 at 19:39 -0300, Alexis Menard wrote:
 To svn user :
 - Conflict resolving much easier and performant than svn (we have
 drivers for changelogs and the default one are much better than svn).
 - Local history/blaming/...
 - Proper diff coloration (though I'm sure you guys have some magic
 scripts using colordiff).
 - The staging area, upload what you want/need and keep some work local
 - Smaller checkouts
 
 - Bot maintainers :
 Power outage or network interruption in the middle of a svn
 checkout/up lock the repo sometimes and you need to manually svn
 cleanup the checkout (maybe someone have a tool or script to avoid
 that???). I had much more svn locked repos than git dead checkout
 because of interruptions.
 
 /me puts his bot maintainer hat on
 
 That does suck indeed. Been a while since I had to manually intervene,
 but even when it is fixed automatically, the new checkout takes ages
 (because the automatic fix is to rm -rf the whole source tree).

The solution for this would be to teach buildbot run 'svn cleanup' when 
necessary rather than just assuming the worst and nuking the working copy. This 
will become trivial to do in future versions of Buildbot as they're moving the 
logic for how version control operations to the server rather than the slaves, 
meaning it becomes much easier to update and customize.

- Mark

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Moving to Git?

2012-03-09 Thread Mark Rowe

On 2012-03-09, at 09:15, Kalle Vahlman kalle.vahl...@gmail.com wrote:

 2012/3/9 Ryosuke Niwa rn...@webkit.org:
 On Fri, Mar 9, 2012 at 7:14 AM, Ashod Nakashian ashodnakash...@yahoo.com
 wrote:
 I think if we address the main issues raised by the svn users, the current
 consensus (if representative) seems to point towards an overwhelming support
 (and demand?) for git over svn. On that point it's reasonable to say that
 we're heading towards option #1 or #2 of Maciej. As such, I'm humbly
 proposing the following (hopefully without getting ahead of myself):
 
 
 Frankly, I don't quite understand the benefit of this transition. Do we
 really need to move to git? If the only problem of keeping svn was about
 svn-apply being broken, I'm more than happy to fix that script.
 
 I think you missed the part where the impact on servers was discussed.
 If every time someone does svn log the server needs to not receive
 or deal out commits, it will show in response times. I'm sure people
 using svn do not check the log often, for obvious reasons, but it is
 still a factor to consider.

Making operations like 'log' not hit the server would obviously be nice, but 
the vast majority of the load on the Subversion server is from update or 
checkout operations.  Do you have a pointer to any concrete data about the 
relative load on a server for Git vs Subversion in terms of these operations?

Thanks,

- Mark


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Moving to Git?

2012-03-09 Thread Mark Rowe

On 2012-03-09, at 07:14, Ashod Nakashian ashodnakash...@yahoo.com wrote:

 
 From: David Barr davidb...@google.com
 To: Ryosuke Niwa rn...@webkit.org 
 Cc: webkit-dev@lists.webkit.org webkit-dev@lists.webkit.org 
 Sent: Friday, March 9, 2012 2:37 AM
 Subject: Re: [webkit-dev] Moving to Git?
 
 
 I think we ought to streamline the git workflow before we start trying
 to proselytise Subversion users. :)
 
 
 
 Can you be more specific? What do you find wanting in the git workflow 
 besides the few cases raised by svn users (such as svn up that can be 
 supported in update-webkit)?
 
 I think if we address the main issues raised by the svn users, the current 
 consensus (if representative) seems to point towards an overwhelming support 
 (and demand?) for git over svn.

What you'll find is that the vast majority of SVN users are simply not 
participating in this email thread. You'll also find that many people that use 
git-svn are happy enough with the status quo since it gives those who chose to 
use it most of the benefits of a pure Git setup without forcing it on others.

In my opinion a substantial benefit needs to be demonstrated in order to 
convince the existing SVN users, many of which are substantial long-term 
contributors to the project, that it's worth it to them to relearn how to 
contribute to WebKit. And I do feel that SVN users need to want to switch to 
Git in order for it to be worth pursuing such a switch. As a heavy Git user 
myself I've not seen any arguments in this thread that would be convincing to 
someone not already familiar with Git.

- Mark

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Moving to Git?

2012-03-09 Thread Maciej Stachowiak

Here's my thoughts based on this and other comments

On Mar 8, 2012, at 2:30 PM, Alexis Menard wrote:

 
 To the global infrastructure :
 - Local history for git. svn log access to the server every time you
 call that command. Will improve the load of the server.
 - Performance of checkouts/pull as data are send compressed from the server.

Sounds like there is some potential benefit here, though we might want to 
explore beefing up the servers before changing the tools.

 
 To git user :
 - Using git push rather than having to use git-svn (which you need to
 keep in sync).
 - Simplified workflow, we don't need to mess with git-svn.
 - Companies who fork (we all do) can simplify their workflow a bit
 regarding branches.

It sounds like avoiding use of git-svn is the big benefit to git users and 
perhaps the reason this topic periodically comes up. Can anyone spell out in 
more detail the benefits of using straight git instead of git-svn?

 
 To svn user :
 - Conflict resolving much easier and performant than svn (we have
 drivers for changelogs and the default one are much better than svn).
 - Local history/blaming/...
 - Proper diff coloration (though I'm sure you guys have some magic
 scripts using colordiff).
 - The staging area, upload what you want/need and keep some work local
 - Smaller checkouts

So far many SVN users haven't found these benefits to exceed the switching 
cost, though perhaps more will be inspired to give git a try by this thread.

Regards,
aciek

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Moving to Git?

2012-03-09 Thread Gustavo Noronha Silva
On Fri, 2012-03-09 at 13:43 -0800, Maciej Stachowiak wrote:
  - Simplified workflow, we don't need to mess with git-svn.
  - Companies who fork (we all do) can simplify their workflow a bit
  regarding branches.
 
 It sounds like avoiding use of git-svn is the big benefit to git users
 and perhaps the reason this topic periodically comes up. Can anyone
 spell out in more detail the benefits of using straight git instead of
 git-svn?

I am a git user, I use git-svn for all my commits and I tend to use git
for every project I create myself outside of WebKit. I see lots of
benefits to using git over svn. However, for a project like WebKit I
think there's really no reason to use git other than people feeling good
about removing git-svn from their systems.

I tend to think there is little or no benefit to switching to git while
keeping all of the project workflow in place. The fact that we would
want to keep a simple history with no merges in it pretty much defeat
any benefit that could be had. I think using git only makes sense if we
adopt git workflows, which would mean people would post git branches
for review instead of patches, and those branches would then get merged.

The one point I think makes a lot of sense to investigate is tools.
People who are maintaining the awesome tools we use today have been
doing a great job of making them work for both git and svn users, but
it's probably a big burden for them. So, if people declare that some
tools will only work with git work directories, I'd be fine with it,
would anyone oppose? We can keep using svn as the central server, but
people wanting to use those tools would have to use git-svn.

Tbh, I am much more interested in doing away with ChangeLogs than in
feeling good about using git push instead of git svn dcommit. If we
could find a way around ChangeLogs while keeping svn, then I would be an
even happier panda than I am today =).

Cheers,

-- 
Gustavo Noronha Silva g...@gnome.org
GNOME Project

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Moving to Git?

2012-03-09 Thread noam . rosenthal

On Mar 9, 2012, at 1:43 PM, ext Maciej Stachowiak wrote:

It sounds like avoiding use of git-svn is the big benefit to git users and 
perhaps the reason this topic periodically comes up. Can anyone spell out in 
more detail the benefits of using straight git instead of git-svn?

My main pain point with the current workflow, which can potentially be repaired 
by using a real git workflow, is the manual changelog editing, rather than 
using commit messages.
With a git workflow we can review commit messages as part of the regular review 
process, which I understand we can't do with SVN (though I don't know SVN that 
well).

Wouldn't a world without manual changelog editing be slightly nicer?
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Moving to Git?

2012-03-09 Thread Emil A Eklund
On Fri, Mar 9, 2012 at 14:46, Adam Treat atr...@rim.com wrote:
 Would be good to know who the remaining svn users are.  And who is using 
 git/git-svn now.  I'd love to see the breakdown.  Data is good.

I'm another svn user and while I'd prefer to keep using svn I'm not
opposed to migrating to git if that is what the majority wants.
Maintaining both certainly seems undesirable in the long run.

--
Emil
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Moving to Git?

2012-03-09 Thread Geoffrey Garen
I'm starting to see a mathematical relationship between
(a) Volume of contribution to the WebKit OpenSource Project
(b) Volume of advocacy for removing svn support from the WebKit OpenSource 
Project

The relationship seems to be of the inverse variety.

In your case, Ashod:

Source find . -name ChangeLog\* | xargs grep Nakashian | wc -l
   2

Geoff

On Mar 9, 2012, at 7:14 AM, Ashod Nakashian wrote:

 I think if we address the main issues raised by the svn users, the current 
 consensus (if representative) seems to point towards an overwhelming support 
 (and demand?) for git over svn. On that point it's reasonable to say that 
 we're heading towards option #1 or #2 of Maciej. As such, I'm humbly 
 proposing the following (hopefully without getting ahead of myself):
 
 A) Address as many of the issues raised by the svn users and streamline their 
 use-cases in the current scripts on top of git that we can (this would leave 
 generation numbers out of scope as it's a git issue, although we can push 
 that on git's mail-list). Address any current issues that (advanced/seasoned) 
 git users find wanting/missing to have a solid system that capitalizes on the 
 powers of git as much as possible.
 
 B) Plan a phase-out schedule for svn repo, servers and scripts and mainlining 
 git (this needs input from ops and those who can assess the overhead involved 
 - something I'm ignorant of). Offer the option of having svn mirror (however 
 realistic that is, I can't tell) keeping in mind the overhead of maintaining 
 the svn scripts.
 
 If we don't do anything we'll be supporting both systems, scripts, docs etc. 
 with little advantage but having the choice of both systems (status-quo). If 
 we start moving towards git I think we'll end up with the reverse situation 
 than what we have now (git mainline, svn mirror) and, assuming the majority 
 use git and there are more benefits to git over svn, then WebKit will benefit 
 more that way than the case is now. However, having said that, something 
 tells me the remaining svn users will probably switch to git sooner rather 
 than later.
 
 (Disclaimer: I enjoy svn as much as the next guy, but I think git offers 
 enough power to justify the overhead of learning/adapting/migrating to it. In 
 addition, as many pointed out, no one has to use all the power features and 
 the svn-equivalent day-to-day ones can be automated transparently by current 
 (and new) scripts.)
 
 -Ash


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Moving to Git?

2012-03-09 Thread Pablo Flouret
On Fri, 09 Mar 2012 14:47:17 -0800, Gustavo Noronha Silva g...@gnome.org  
wrote:



I tend to think there is little or no benefit to switching to git while
keeping all of the project workflow in place. The fact that we would
want to keep a simple history with no merges in it pretty much defeat
any benefit that could be had. I think using git only makes sense if we
adopt git workflows, which would mean people would post git branches
for review instead of patches, and those branches would then get merged.


I agree.
I've lived through a large-scale git migration (from CVS, though, so it  
had literally zero opposition from people, the big issue was  
infrastructure constraints), and one of the greatest benefits was the  
breadth of workflows git allows to choose from, so if people are mostly  
happy with the current workflow, then if it ain't broke, don't fix it  
probably applies.


Otherwise, the question might be how much easier would it be to experiment  
with new workflows if we got rid of subversion altogether. Or if people  
want to think about new workflows at all, for that matter.




Tbh, I am much more interested in doing away with ChangeLogs than in
feeling good about using git push instead of git svn dcommit. If we
could find a way around ChangeLogs while keeping svn, then I would be an
even happier panda than I am today =).


+1

--
pablo flouret
motorola | webkit / browser team
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Moving to Git?

2012-03-09 Thread Ashod Nakashian
- Original Message -

 From: Geoffrey Garen gga...@apple.com
 To: Ashod Nakashian ashodnakash...@yahoo.com
 Cc: David Barr davidb...@google.com; Ryosuke Niwa rn...@webkit.org; 
 WebKit Development webkit-dev@lists.webkit.org
 Sent: Saturday, March 10, 2012 2:58 AM
 Subject: Re: [webkit-dev] Moving to Git?
 
 I'm starting to see a mathematical relationship between
 (a) Volume of contribution to the WebKit OpenSource Project
 (b) Volume of advocacy for removing svn support from the WebKit OpenSource 
 Project
 
 The relationship seems to be of the inverse variety.
 
 In your case, Ashod:
 
 Source find . -name ChangeLog\* | xargs grep Nakashian | wc 
 -l
        2
 

I'm sorry if I don't see why this is a good argument. Is there a prerequisite 
for resurrecting a healthy discussion on a topic that is obviously of interest 
to many active contributes that I'm not aware of?

After all, what prompted me to raise this issue is because some svn scripts are 
outdated and before fixing them I thought may be there wasn't much use for them 
in the first place (otherwise, someone with a bigger contribution volume would 
certainly have noticed and fixed them sooner than me).

-Ash

 Geoff
 
 On Mar 9, 2012, at 7:14 AM, Ashod Nakashian wrote:
 
  I think if we address the main issues raised by the svn users, the current 
 consensus (if representative) seems to point towards an overwhelming support 
 (and demand?) for git over svn. On that point it's reasonable to say that 
 we're heading towards option #1 or #2 of Maciej. As such, I'm humbly 
 proposing the following (hopefully without getting ahead of myself):
 
  A) Address as many of the issues raised by the svn users and streamline 
 their use-cases in the current scripts on top of git that we can (this would 
 leave generation numbers out of scope as it's a git issue, although we can 
 push that on git's mail-list). Address any current issues that 
 (advanced/seasoned) git users find wanting/missing to have a solid system 
 that 
 capitalizes on the powers of git as much as possible.
 
  B) Plan a phase-out schedule for svn repo, servers and scripts and 
 mainlining git (this needs input from ops and those who can assess the 
 overhead 
 involved - something I'm ignorant of). Offer the option of having svn mirror 
 (however realistic that is, I can't tell) keeping in mind the overhead of 
 maintaining the svn scripts.
 
  If we don't do anything we'll be supporting both systems, scripts, 
 docs etc. with little advantage but having the choice of both systems 
 (status-quo). If we start moving towards git I think we'll end up with the 
 reverse situation than what we have now (git mainline, svn mirror) and, 
 assuming 
 the majority use git and there are more benefits to git over svn, then WebKit 
 will benefit more that way than the case is now. However, having said that, 
 something tells me the remaining svn users will probably switch to git sooner 
 rather than later.
 
  (Disclaimer: I enjoy svn as much as the next guy, but I think git offers 
 enough power to justify the overhead of learning/adapting/migrating to it. In 
 addition, as many pointed out, no one has to use all the power features and 
 the 
 svn-equivalent day-to-day ones can be automated transparently by current (and 
 new) scripts.)
 
  -Ash
 
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Moving to Git?

2012-03-09 Thread Ryosuke Niwa
First, a follow up on my old post since my message was cut off in the
middle:
On Thu, Mar 8, 2012 at 1:25 PM, Ryosuke Niwa rn...@webkit.org wrote:

 On Thu, Mar 8, 2012 at 1:19 PM, Joe Mason jma...@rim.com wrote:

 This is only slightly more complicated


 I'd say astoundingly more complicated because of


the fact that you're unapplying changes, updating the checkout, and
reapplying changes. This seemingly innocent sequence of operations have an
annoying side-effects of touching all files you've modified locally and
haven't committed.

So for example if you have any changes to Node.h and run this set of
operations, then git will touch Node.h twice by stashing and applying. This
would mean that I would be rebuilding the world even if all changes I get
from masters were in webkitpy or LayoutTests.

Are there an easy way to work around this issue as well? (other than
committing changes, of course)

On Fri, Mar 9, 2012 at 3:54 PM, Ashod Nakashian ashodnakash...@yahoo.comwrote:

 After all, what prompted me to raise this issue is because some svn
 scripts are outdated and before fixing them I thought may be there wasn't
 much use for them in the first place (otherwise, someone with a bigger
 contribution volume would certainly have noticed and fixed them sooner than
 me).


I suspect the only reason the particular bug hadn't been fixed is that we
have very few contributors who develop on Windows.

- Ryosuke
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Moving to Git?

2012-03-09 Thread David Levin
On Fri, Mar 9, 2012 at 4:01 PM, Ryosuke Niwa rn...@webkit.org wrote:


  git will touch Node.h twice by stashing and applying. This would mean
 that I would be rebuilding the world even if all changes I get from masters
 were in webkitpy or LayoutTests.

 Are there an easy way to work around this issue as well? (other than
 committing changes, of course)


afaik not really, here's two that I've used:

   1. git-new-workdir (multiple git working dirs so I don't switch branches
   as often)
   2. ccache (cache the results of the compile)

 dave
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Moving to Git?

2012-03-09 Thread Ryosuke Niwa
On Mar 9, 2012 3:16 PM, Pablo Flouret pab...@motorola.com wrote:

 On Fri, 09 Mar 2012 14:47:17 -0800, Gustavo Noronha Silva g...@gnome.org
wrote:
 Tbh, I am much more interested in doing away with ChangeLogs than in
 feeling good about using git push instead of git svn dcommit. If we
 could find a way around ChangeLogs while keeping svn, then I would be an
 even happier panda than I am today =).

 +1

We can do this without moving to git. Here's how it might work:
1. When writing a patch, add a new temporary file e.g. ChangeLogEntry that
stores new change log entry in each directory where ChangeLogs are located.
2. ChangeLogEntry files are added to git/svn checkouts
3. Upload the patch (including ChangeLogEntry) for a review. Bugzilla shows
ChangeLogEntry filesas new files (can be tweeked,of course)
4. Once you get r+, you land the patch. The commit message editor will
automatically find ChangeLogEntry files and aggregate the result as the
commit message.
5. You commit. The commit hook ensures no ChangeLogEntry files are actually
committed into the svn repository.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Moving to Git?

2012-03-09 Thread Pablo Flouret

On Fri, 09 Mar 2012 17:55:59 -0800, Ryosuke Niwa rn...@webkit.org wrote:


On Mar 9, 2012 3:16 PM, Pablo Flouret pab...@motorola.com wrote:


On Fri, 09 Mar 2012 14:47:17 -0800, Gustavo Noronha Silva  
g...@gnome.org

wrote:

Tbh, I am much more interested in doing away with ChangeLogs than in
feeling good about using git push instead of git svn dcommit. If we
could find a way around ChangeLogs while keeping svn, then I would be  
an

even happier panda than I am today =).


+1


We can do this without moving to git. Here's how it might work:
1. When writing a patch, add a new temporary file e.g. ChangeLogEntry  
that
stores new change log entry in each directory where ChangeLogs are  
located.

2. ChangeLogEntry files are added to git/svn checkouts
3. Upload the patch (including ChangeLogEntry) for a review. Bugzilla  
shows

ChangeLogEntry filesas new files (can be tweeked,of course)
4. Once you get r+, you land the patch. The commit message editor will
automatically find ChangeLogEntry files and aggregate the result as the
commit message.
5. You commit. The commit hook ensures no ChangeLogEntry files are  
actually

committed into the svn repository.


That doesn't sound like much of an improvement.

I'd prefer to see something closer to what 'git format-patch' spits out.
Basically you give it a commit range and it spits out one diff per commit,  
including the commit message.


This gives a couple of interesting options, like having a single patch  
which can contain multiple commits. Or you can do some mangling like  
webkit-patch does today to take a commit-range diff and pretend that it's  
a single commit.
I imagine it shouldn't be too hard to replicate the format for someone  
using just svn.
A tool's UI for editing the commit message for svn users (or for the  
squash case) could somewhat mirror what the git rebase ui does for  
squashing. So you'd have a patch that includes commit messages ready for  
reviewers' perusal (which i presume is the biggest reason changelogs still  
exist?)


In my most frequent workflow i make a patch, submit it, make a local  
commit in git for myself (in a branch) and then move on to other things  
(in a different branch perhaps). Then when review comments come in, i  
address them, make a local commit with those changes, and upload a patch  
by giving a range to webkit-patch. ChangeLog files are a pain in the ass  
in this case. Also, reviewers don't get to see what changed between the  
two patches i uploaded, which a patch coming from format-patch would show.  
A final, squashed patch could be required for landing. Or both types could  
be submitted through webkit-patch and available in bugzilla. Or something  
else.


Anyway, just brainstorming a bit, haven't thought this through that much.

--
pablo flouret
motorola | webkit / browser team
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Moving to Git?

2012-03-09 Thread Kalle Vahlman
2012/3/9 Mark Rowe mr...@apple.com:

 On 2012-03-09, at 09:15, Kalle Vahlman kalle.vahl...@gmail.com wrote:

 2012/3/9 Ryosuke Niwa rn...@webkit.org:
 Frankly, I don't quite understand the benefit of this transition. Do we
 really need to move to git? If the only problem of keeping svn was about
 svn-apply being broken, I'm more than happy to fix that script.

 I think you missed the part where the impact on servers was discussed.
 If every time someone does svn log the server needs to not receive
 or deal out commits, it will show in response times. I'm sure people
 using svn do not check the log often, for obvious reasons, but it is
 still a factor to consider.

 Making operations like 'log' not hit the server would obviously be nice, but 
 the vast majority of the
 load on the Subversion server is from update or checkout operations.  Do you 
 have a pointer to any
 concrete data about the relative load on a server for Git vs Subversion in 
 terms of these operations?

I'm afraid not, just bits and pieces about performance and bandwidth
usage that mostly amount just to a gut feeling.

Googling also turned up zero studies from server POV. As said there is
some evidence that repository size is reduced and that network
bandwidth usage can be better with git, but considering how different
workflows can emerge at least the bandwidth usage can not be mapped
1:1 to actual deployment.

Another consideration here is that git-svn can be rather abusive for
the server if used wrong, so if svn is no longer the central VCS that
use case will also vanish, further changing the usage patterns.

The only way to _truly_ know would be to have graphs from a server
that hosted similar class project using svn then switched to git (or
vice versa!) and even then it would be dependent on the workflows
used...

-- 
Kalle Vahlman, z...@iki.fi
Powered by http://movial.com
Interesting stuff at http://sandbox.movial.com
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


[webkit-dev] Moving to Git?

2012-03-08 Thread Ashod Nakashian
WebKittens,

In the light of discovering that some SVN scripts have fallen behind in terms 
of maintenance[1] and WebKit's strong Git support and infrastructure, against 
my better judgement, I'd like to distract you from being productive by bringing 
up this topic (again).

The wiki page of the same name[2] was created 3 years ago and hardly updated 
since[3]. I know we're all busy with more important things, but IMHO I think we 
can at least update the wiki and perhaps vote on when/how we should do the 
eventual transition.

I understand that while this type of work isn't necessarily very productive, 
maintaining two repositories and sets of scripts (with their docs and issues) 
has a very real cost as well. I'm proposing we reevaluate the situation and act 
accordingly.

[1] https://bugs.webkit.org/show_bug.cgi?id=79509#c6

[2] http://trac.webkit.org/wiki/Moving%20to%20Git
[3] http://trac.webkit.org/wiki/Moving%20to%20Git?action=history

Thanks for lending an ear,
-Ash___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Moving to Git?

2012-03-08 Thread Sergio Villar Senin
En 08/03/12 13:35, Ashod Nakashian escribiu:
 WebKittens,
 
 In the light of discovering that some SVN scripts have fallen behind in
 terms of maintenance[1] and WebKit's strong Git support and
 infrastructure, against my better judgement, I'd like to distract you
 from being productive by bringing up this topic (again).

Please correct me if I'm wrong but IIRC the main blocker was that any
user with an standard OS X setup should be able to start hacking on
WebKit without having to install any additional dependency. SVN is
shipped with OS X and git is not.

Anyway I'd be really pleased if that move happens.

BR

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Moving to Git?

2012-03-08 Thread Jarred Nicholls
On Thu, Mar 8, 2012 at 7:46 AM, Sergio Villar Senin svil...@igalia.comwrote:

 En 08/03/12 13:35, Ashod Nakashian escribiu:
  WebKittens,
 
  In the light of discovering that some SVN scripts have fallen behind in
  terms of maintenance[1] and WebKit's strong Git support and
  infrastructure, against my better judgement, I'd like to distract you
  from being productive by bringing up this topic (again).

 Please correct me if I'm wrong but IIRC the main blocker was that any
 user with an standard OS X setup should be able to start hacking on
 WebKit without having to install any additional dependency. SVN is
 shipped with OS X and git is not.


A version of git ships with Xcode, and without Xcode I don't think anyone
attempting to hack on WebKit will get very far :3



 Anyway I'd be really pleased if that move happens.

 BR

 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Moving to Git?

2012-03-08 Thread Konrad Piascik
I personally use either git or git-svn and would welcome the move.

-Konrad

From: webkit-dev-boun...@lists.webkit.org [webkit-dev-boun...@lists.webkit.org] 
on behalf of Ashod Nakashian [ashodnakash...@yahoo.com]
Sent: Thursday, March 08, 2012 8:56 AM
To: Sergio Villar Senin
Cc: WebKit Development
Subject: Re: [webkit-dev] Moving to Git?


 From: Sergio Villar Senin svil...@igalia.com
To: webkit-dev@lists.webkit.org
Sent: Thursday, March 8, 2012 4:46 PM
Subject: Re: [webkit-dev] Moving to Git?

En 08/03/12 13:35, Ashod Nakashian escribiu:
 WebKittens,

 In the light of discovering that some SVN scripts have fallen behind in
 terms of maintenance[1] and WebKit's strong Git support and
 infrastructure, against my better judgement, I'd like to distract you
 from being productive by bringing up this topic (again).

Please correct me if I'm wrong but IIRC the main blocker was that any
user with an standard OS X setup should be able to start hacking on
WebKit without having to install any additional dependency. SVN is
shipped with OS X and git is not.

Ahh, the days when one didn't have to download anything to start hacking 
away... But seriously, why should I care about OS X when Windows comes packed 
with git?/sarcasm


Anyway I'd be really pleased if that move happens.

Same here. And my hope is that there are many more of us.


BR

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev



___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Moving to Git?

2012-03-08 Thread Ryosuke Niwa
On Thu, Mar 8, 2012 at 4:35 AM, Ashod Nakashian ashodnakash...@yahoo.comwrote:

 In the light of discovering that some SVN scripts have fallen behind in
 terms of maintenance[1] and WebKit's strong Git support and infrastructure,
 against my better judgement, I'd like to distract you from being productive
 by bringing up this topic (again).

 The wiki page of the same name[2] was created 3 years ago and hardly
 updated since[3]. I know we're all busy with more important things, but
 IMHO I think we can at least update the wiki and perhaps vote on when/how
 we should do the eventual transition.

 I understand that while this type of work isn't necessarily very
 productive, maintaining two repositories and sets of scripts (with their
 docs and issues) has a very real cost as well. I'm proposing we reevaluate
 the situation and act accordingly.


Re-evaluating the situation is good, but I'm still opposed.

- Ryosuke
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Moving to Git?

2012-03-08 Thread Alexis Menard
On Thu, Mar 8, 2012 at 2:03 PM, Ryosuke Niwa rn...@webkit.org wrote:
 On Thu, Mar 8, 2012 at 4:35 AM, Ashod Nakashian ashodnakash...@yahoo.com
 wrote:

 In the light of discovering that some SVN scripts have fallen behind in
 terms of maintenance[1] and WebKit's strong Git support and infrastructure,
 against my better judgement, I'd like to distract you from being productive
 by bringing up this topic (again).

 The wiki page of the same name[2] was created 3 years ago and hardly
 updated since[3]. I know we're all busy with more important things, but IMHO
 I think we can at least update the wiki and perhaps vote on when/how we
 should do the eventual transition.

 I understand that while this type of work isn't necessarily very
 productive, maintaining two repositories and sets of scripts (with their
 docs and issues) has a very real cost as well. I'm proposing we reevaluate
 the situation and act accordingly.


 Re-evaluating the situation is good, but I'm still opposed.

I don't use svn but the only benefit I see of WebKit using svn is the
linear history, clean, easy to read and to explore. Git repos tend to
have merging commits a lot and it leads to make bisecting/history
browsing harder (my taste).

Then for everything else I use git and its power locally.


 - Ryosuke


 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev




-- 
Alexis Menard (darktears)
Software Engineer
INdT Recife Brazil
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Moving to Git?

2012-03-08 Thread Ryosuke Niwa
On Thu, Mar 8, 2012 at 9:10 AM, Alexis Menard
alexis.men...@openbossa.orgwrote:

 I don't use svn but the only benefit I see of WebKit using svn is the
 linear history, clean, easy to read and to explore. Git repos tend to
 have merging commits a lot and it leads to make bisecting/history
 browsing harder (my taste).


And that's a show stopper for me. For build bot maintenance, regression
fixes, etc... being able to easily tell the number of commits between two
revisions (in my head as opposed to using a tool) or the ordering of
commits is crucial.

Then for everything else I use git and its power locally.


Right. Git clients are pretty nice.

- Ryosuke
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Moving to Git?

2012-03-08 Thread Carlos Garcia Campos
El jue, 08-03-2012 a las 14:10 -0300, Alexis Menard escribió:
 On Thu, Mar 8, 2012 at 2:03 PM, Ryosuke Niwa rn...@webkit.org wrote:
  On Thu, Mar 8, 2012 at 4:35 AM, Ashod Nakashian ashodnakash...@yahoo.com
  wrote:
 
  In the light of discovering that some SVN scripts have fallen behind in
  terms of maintenance[1] and WebKit's strong Git support and infrastructure,
  against my better judgement, I'd like to distract you from being productive
  by bringing up this topic (again).
 
  The wiki page of the same name[2] was created 3 years ago and hardly
  updated since[3]. I know we're all busy with more important things, but 
  IMHO
  I think we can at least update the wiki and perhaps vote on when/how we
  should do the eventual transition.
 
  I understand that while this type of work isn't necessarily very
  productive, maintaining two repositories and sets of scripts (with their
  docs and issues) has a very real cost as well. I'm proposing we reevaluate
  the situation and act accordingly.
 
 
  Re-evaluating the situation is good, but I'm still opposed.
 
 I don't use svn but the only benefit I see of WebKit using svn is the
 linear history, clean, easy to read and to explore. Git repos tend to
 have merging commits a lot and it leads to make bisecting/history
 browsing harder (my taste).

I agree about merging commits, but I think it's possible to enforce all
merges to be fast-forward and without merging commits. In general
browsing git history is easier and cleaner than svn, and more important
it's much faster (my taste :-P)

 Then for everything else I use git and its power locally.

I would be more than happy with the switch :-)

-- 
Carlos Garcia Campos
http://pgp.rediris.es:11371/pks/lookup?op=getsearch=0xF3D322D0EC4582C3

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Moving to Git?

2012-03-08 Thread Philippe Normand
On Thu, 2012-03-08 at 14:10 -0300, Alexis Menard wrote:
 On Thu, Mar 8, 2012 at 2:03 PM, Ryosuke Niwa rn...@webkit.org wrote:
  On Thu, Mar 8, 2012 at 4:35 AM, Ashod Nakashian ashodnakash...@yahoo.com
  wrote:
 
  In the light of discovering that some SVN scripts have fallen behind in
  terms of maintenance[1] and WebKit's strong Git support and infrastructure,
  against my better judgement, I'd like to distract you from being productive
  by bringing up this topic (again).
 
  The wiki page of the same name[2] was created 3 years ago and hardly
  updated since[3]. I know we're all busy with more important things, but 
  IMHO
  I think we can at least update the wiki and perhaps vote on when/how we
  should do the eventual transition.
 
  I understand that while this type of work isn't necessarily very
  productive, maintaining two repositories and sets of scripts (with their
  docs and issues) has a very real cost as well. I'm proposing we reevaluate
  the situation and act accordingly.
 
 
  Re-evaluating the situation is good, but I'm still opposed.
 
 I don't use svn but the only benefit I see of WebKit using svn is the
 linear history, clean, easy to read and to explore. Git repos tend to
 have merging commits a lot and it leads to make bisecting/history
 browsing harder (my taste).
 

We just need to keep the history linear. With good practices it's
possible :)

Philippe


signature.asc
Description: This is a digitally signed message part
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Moving to Git?

2012-03-08 Thread Konrad Piascik
It is possible to keep linear history with git.  This just requires you to fast 
forward and rebase before pushing.
Konrad
Sent from my BlackBerry on the Rogers Wireless Network

- Original Message -
From: Carlos Garcia Campos [mailto:carlo...@webkit.org]
Sent: Thursday, March 08, 2012 12:27 PM
To: webkit-dev@lists.webkit.org webkit-dev@lists.webkit.org
Subject: Re: [webkit-dev] Moving to Git?

El jue, 08-03-2012 a las 14:10 -0300, Alexis Menard escribió:
 On Thu, Mar 8, 2012 at 2:03 PM, Ryosuke Niwa rn...@webkit.org wrote:
  On Thu, Mar 8, 2012 at 4:35 AM, Ashod Nakashian ashodnakash...@yahoo.com
  wrote:
 
  In the light of discovering that some SVN scripts have fallen behind in
  terms of maintenance[1] and WebKit's strong Git support and infrastructure,
  against my better judgement, I'd like to distract you from being productive
  by bringing up this topic (again).
 
  The wiki page of the same name[2] was created 3 years ago and hardly
  updated since[3]. I know we're all busy with more important things, but 
  IMHO
  I think we can at least update the wiki and perhaps vote on when/how we
  should do the eventual transition.
 
  I understand that while this type of work isn't necessarily very
  productive, maintaining two repositories and sets of scripts (with their
  docs and issues) has a very real cost as well. I'm proposing we reevaluate
  the situation and act accordingly.
 
 
  Re-evaluating the situation is good, but I'm still opposed.
 
 I don't use svn but the only benefit I see of WebKit using svn is the
 linear history, clean, easy to read and to explore. Git repos tend to
 have merging commits a lot and it leads to make bisecting/history
 browsing harder (my taste).

I agree about merging commits, but I think it's possible to enforce all
merges to be fast-forward and without merging commits. In general
browsing git history is easier and cleaner than svn, and more important
it's much faster (my taste :-P)

 Then for everything else I use git and its power locally.

I would be more than happy with the switch :-)

-- 
Carlos Garcia Campos
http://pgp.rediris.es:11371/pks/lookup?op=getsearch=0xF3D322D0EC4582C3

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Moving to Git?

2012-03-08 Thread Alexis Menard
On Thu, Mar 8, 2012 at 2:32 PM, Konrad Piascik kpias...@rim.com wrote:
 It is possible to keep linear history with git.  This just requires you to 
 fast forward and rebase before pushing.

But can you enforce in the server? To avoid people to push it by mistake?

 Konrad
 Sent from my BlackBerry on the Rogers Wireless Network

 - Original Message -
 From: Carlos Garcia Campos [mailto:carlo...@webkit.org]
 Sent: Thursday, March 08, 2012 12:27 PM
 To: webkit-dev@lists.webkit.org webkit-dev@lists.webkit.org
 Subject: Re: [webkit-dev] Moving to Git?

 El jue, 08-03-2012 a las 14:10 -0300, Alexis Menard escribió:
 On Thu, Mar 8, 2012 at 2:03 PM, Ryosuke Niwa rn...@webkit.org wrote:
  On Thu, Mar 8, 2012 at 4:35 AM, Ashod Nakashian ashodnakash...@yahoo.com
  wrote:
 
  In the light of discovering that some SVN scripts have fallen behind in
  terms of maintenance[1] and WebKit's strong Git support and 
  infrastructure,
  against my better judgement, I'd like to distract you from being 
  productive
  by bringing up this topic (again).
 
  The wiki page of the same name[2] was created 3 years ago and hardly
  updated since[3]. I know we're all busy with more important things, but 
  IMHO
  I think we can at least update the wiki and perhaps vote on when/how we
  should do the eventual transition.
 
  I understand that while this type of work isn't necessarily very
  productive, maintaining two repositories and sets of scripts (with their
  docs and issues) has a very real cost as well. I'm proposing we reevaluate
  the situation and act accordingly.
 
 
  Re-evaluating the situation is good, but I'm still opposed.

 I don't use svn but the only benefit I see of WebKit using svn is the
 linear history, clean, easy to read and to explore. Git repos tend to
 have merging commits a lot and it leads to make bisecting/history
 browsing harder (my taste).

 I agree about merging commits, but I think it's possible to enforce all
 merges to be fast-forward and without merging commits. In general
 browsing git history is easier and cleaner than svn, and more important
 it's much faster (my taste :-P)

 Then for everything else I use git and its power locally.

 I would be more than happy with the switch :-)

 --
 Carlos Garcia Campos
 http://pgp.rediris.es:11371/pks/lookup?op=getsearch=0xF3D322D0EC4582C3

 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

 -
 This transmission (including any attachments) may contain confidential 
 information, privileged material (including material protected by the 
 solicitor-client or other applicable privileges), or constitute non-public 
 information. Any use of this information by anyone other than the intended 
 recipient is prohibited. If you have received this transmission in error, 
 please immediately reply to the sender and delete this information from your 
 system. Use, dissemination, distribution, or reproduction of this 
 transmission by unintended recipients is not authorized and may be unlawful.
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev



-- 
Alexis Menard (darktears)
Software Engineer
INdT Recife Brazil
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Moving to Git?

2012-03-08 Thread Dana Jansens
On Thu, Mar 8, 2012 at 12:35 PM, Alexis Menard
alexis.men...@openbossa.orgwrote:

 On Thu, Mar 8, 2012 at 2:32 PM, Konrad Piascik kpias...@rim.com wrote:
  It is possible to keep linear history with git.  This just requires you
 to fast forward and rebase before pushing.

 But can you enforce in the server? To avoid people to push it by mistake?


http://progit.org/book/ch7-4.html

  Konrad
  Sent from my BlackBerry on the Rogers Wireless Network
 
  - Original Message -
  From: Carlos Garcia Campos [mailto:carlo...@webkit.org]
  Sent: Thursday, March 08, 2012 12:27 PM
  To: webkit-dev@lists.webkit.org webkit-dev@lists.webkit.org
  Subject: Re: [webkit-dev] Moving to Git?
 
  El jue, 08-03-2012 a las 14:10 -0300, Alexis Menard escribió:
  On Thu, Mar 8, 2012 at 2:03 PM, Ryosuke Niwa rn...@webkit.org wrote:
   On Thu, Mar 8, 2012 at 4:35 AM, Ashod Nakashian 
 ashodnakash...@yahoo.com
   wrote:
  
   In the light of discovering that some SVN scripts have fallen behind
 in
   terms of maintenance[1] and WebKit's strong Git support and
 infrastructure,
   against my better judgement, I'd like to distract you from being
 productive
   by bringing up this topic (again).
  
   The wiki page of the same name[2] was created 3 years ago and hardly
   updated since[3]. I know we're all busy with more important things,
 but IMHO
   I think we can at least update the wiki and perhaps vote on when/how
 we
   should do the eventual transition.
  
   I understand that while this type of work isn't necessarily very
   productive, maintaining two repositories and sets of scripts (with
 their
   docs and issues) has a very real cost as well. I'm proposing we
 reevaluate
   the situation and act accordingly.
  
  
   Re-evaluating the situation is good, but I'm still opposed.
 
  I don't use svn but the only benefit I see of WebKit using svn is the
  linear history, clean, easy to read and to explore. Git repos tend to
  have merging commits a lot and it leads to make bisecting/history
  browsing harder (my taste).
 
  I agree about merging commits, but I think it's possible to enforce all
  merges to be fast-forward and without merging commits. In general
  browsing git history is easier and cleaner than svn, and more important
  it's much faster (my taste :-P)
 
  Then for everything else I use git and its power locally.
 
  I would be more than happy with the switch :-)
 
  --
  Carlos Garcia Campos
  http://pgp.rediris.es:11371/pks/lookup?op=getsearch=0xF3D322D0EC4582C3
 
  ___
  webkit-dev mailing list
  webkit-dev@lists.webkit.org
  http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 
  -
  This transmission (including any attachments) may contain confidential
 information, privileged material (including material protected by the
 solicitor-client or other applicable privileges), or constitute non-public
 information. Any use of this information by anyone other than the intended
 recipient is prohibited. If you have received this transmission in error,
 please immediately reply to the sender and delete this information from
 your system. Use, dissemination, distribution, or reproduction of this
 transmission by unintended recipients is not authorized and may be unlawful.
  ___
  webkit-dev mailing list
  webkit-dev@lists.webkit.org
  http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev



 --
 Alexis Menard (darktears)
 Software Engineer
 INdT Recife Brazil
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Moving to Git?

2012-03-08 Thread Carlos Garcia Campos
El jue, 08-03-2012 a las 14:35 -0300, Alexis Menard escribió:
 On Thu, Mar 8, 2012 at 2:32 PM, Konrad Piascik kpias...@rim.com wrote:
  It is possible to keep linear history with git.  This just requires you to 
  fast forward and rebase before pushing.
 
 But can you enforce in the server? To avoid people to push it by mistake?

Yes, I think it's possible with a hook in the server.

  Konrad
  Sent from my BlackBerry on the Rogers Wireless Network
 
  - Original Message -
  From: Carlos Garcia Campos [mailto:carlo...@webkit.org]
  Sent: Thursday, March 08, 2012 12:27 PM
  To: webkit-dev@lists.webkit.org webkit-dev@lists.webkit.org
  Subject: Re: [webkit-dev] Moving to Git?
 
  El jue, 08-03-2012 a las 14:10 -0300, Alexis Menard escribió:
  On Thu, Mar 8, 2012 at 2:03 PM, Ryosuke Niwa rn...@webkit.org wrote:
   On Thu, Mar 8, 2012 at 4:35 AM, Ashod Nakashian 
   ashodnakash...@yahoo.com
   wrote:
  
   In the light of discovering that some SVN scripts have fallen behind in
   terms of maintenance[1] and WebKit's strong Git support and 
   infrastructure,
   against my better judgement, I'd like to distract you from being 
   productive
   by bringing up this topic (again).
  
   The wiki page of the same name[2] was created 3 years ago and hardly
   updated since[3]. I know we're all busy with more important things, but 
   IMHO
   I think we can at least update the wiki and perhaps vote on when/how we
   should do the eventual transition.
  
   I understand that while this type of work isn't necessarily very
   productive, maintaining two repositories and sets of scripts (with their
   docs and issues) has a very real cost as well. I'm proposing we 
   reevaluate
   the situation and act accordingly.
  
  
   Re-evaluating the situation is good, but I'm still opposed.
 
  I don't use svn but the only benefit I see of WebKit using svn is the
  linear history, clean, easy to read and to explore. Git repos tend to
  have merging commits a lot and it leads to make bisecting/history
  browsing harder (my taste).
 
  I agree about merging commits, but I think it's possible to enforce all
  merges to be fast-forward and without merging commits. In general
  browsing git history is easier and cleaner than svn, and more important
  it's much faster (my taste :-P)
 
  Then for everything else I use git and its power locally.
 
  I would be more than happy with the switch :-)
 
  --
  Carlos Garcia Campos
  http://pgp.rediris.es:11371/pks/lookup?op=getsearch=0xF3D322D0EC4582C3
 
  ___
  webkit-dev mailing list
  webkit-dev@lists.webkit.org
  http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 
  -
  This transmission (including any attachments) may contain confidential 
  information, privileged material (including material protected by the 
  solicitor-client or other applicable privileges), or constitute non-public 
  information. Any use of this information by anyone other than the intended 
  recipient is prohibited. If you have received this transmission in error, 
  please immediately reply to the sender and delete this information from 
  your system. Use, dissemination, distribution, or reproduction of this 
  transmission by unintended recipients is not authorized and may be unlawful.
  ___
  webkit-dev mailing list
  webkit-dev@lists.webkit.org
  http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 
 
 


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Moving to Git?

2012-03-08 Thread Adam Treat
Indeed it is.

From: webkit-dev-boun...@lists.webkit.org [webkit-dev-boun...@lists.webkit.org] 
on behalf of Carlos Garcia Campos [carlo...@webkit.org]
Sent: Thursday, March 08, 2012 12:38 PM
To: Alexis Menard
Cc: webkit-dev@lists.webkit.org
Subject: Re: [webkit-dev] Moving to Git?

El jue, 08-03-2012 a las 14:35 -0300, Alexis Menard escribió:
 On Thu, Mar 8, 2012 at 2:32 PM, Konrad Piascik kpias...@rim.com wrote:
  It is possible to keep linear history with git.  This just requires you to 
  fast forward and rebase before pushing.

 But can you enforce in the server? To avoid people to push it by mistake?

Yes, I think it's possible with a hook in the server.

  Konrad
  Sent from my BlackBerry on the Rogers Wireless Network
 
  - Original Message -
  From: Carlos Garcia Campos [mailto:carlo...@webkit.org]
  Sent: Thursday, March 08, 2012 12:27 PM
  To: webkit-dev@lists.webkit.org webkit-dev@lists.webkit.org
  Subject: Re: [webkit-dev] Moving to Git?
 
  El jue, 08-03-2012 a las 14:10 -0300, Alexis Menard escribió:
  On Thu, Mar 8, 2012 at 2:03 PM, Ryosuke Niwa rn...@webkit.org wrote:
   On Thu, Mar 8, 2012 at 4:35 AM, Ashod Nakashian 
   ashodnakash...@yahoo.com
   wrote:
  
   In the light of discovering that some SVN scripts have fallen behind in
   terms of maintenance[1] and WebKit's strong Git support and 
   infrastructure,
   against my better judgement, I'd like to distract you from being 
   productive
   by bringing up this topic (again).
  
   The wiki page of the same name[2] was created 3 years ago and hardly
   updated since[3]. I know we're all busy with more important things, but 
   IMHO
   I think we can at least update the wiki and perhaps vote on when/how we
   should do the eventual transition.
  
   I understand that while this type of work isn't necessarily very
   productive, maintaining two repositories and sets of scripts (with their
   docs and issues) has a very real cost as well. I'm proposing we 
   reevaluate
   the situation and act accordingly.
  
  
   Re-evaluating the situation is good, but I'm still opposed.
 
  I don't use svn but the only benefit I see of WebKit using svn is the
  linear history, clean, easy to read and to explore. Git repos tend to
  have merging commits a lot and it leads to make bisecting/history
  browsing harder (my taste).
 
  I agree about merging commits, but I think it's possible to enforce all
  merges to be fast-forward and without merging commits. In general
  browsing git history is easier and cleaner than svn, and more important
  it's much faster (my taste :-P)
 
  Then for everything else I use git and its power locally.
 
  I would be more than happy with the switch :-)
 
  --
  Carlos Garcia Campos
  http://pgp.rediris.es:11371/pks/lookup?op=getsearch=0xF3D322D0EC4582C3
 
  ___
  webkit-dev mailing list
  webkit-dev@lists.webkit.org
  http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 
  -
  This transmission (including any attachments) may contain confidential 
  information, privileged material (including material protected by the 
  solicitor-client or other applicable privileges), or constitute non-public 
  information. Any use of this information by anyone other than the intended 
  recipient is prohibited. If you have received this transmission in error, 
  please immediately reply to the sender and delete this information from 
  your system. Use, dissemination, distribution, or reproduction of this 
  transmission by unintended recipients is not authorized and may be unlawful.
  ___
  webkit-dev mailing list
  webkit-dev@lists.webkit.org
  http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev





___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Moving to Git?

2012-03-08 Thread Tor Arne Vestbø

On 08.03.12 18:22, Geoffrey Garen wrote:

Rather than asking for a switch to git by fiat, why not improve git and
our git-related infrastructure to the point where people choose to
switch naturally?

The fact that many valuable contributors choose not to use git is
sufficient proof that switching by fiat would be a bad idea.


That's a good point. I'm curious though, what are the main sicking points?

tor arne

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Moving to Git?

2012-03-08 Thread Ashod Nakashian




 From: Ryosuke Niwa rn...@webkit.org
To: Alexis Menard alexis.men...@openbossa.org 
Cc: Ashod Nakashian ashodnakash...@yahoo.com; WebKit Development 
webkit-dev@lists.webkit.org 
Sent: Thursday, March 8, 2012 9:19 PM
Subject: Re: [webkit-dev] Moving to Git?
 

On Thu, Mar 8, 2012 at 9:10 AM, Alexis Menard alexis.men...@openbossa.org 
wrote:
I don't use svn but the only benefit I see of WebKit using svn is the
linear history, clean, easy to read and to explore. Git repos tend to
have merging commits a lot and it leads to make bisecting/history
browsing harder (my taste).



And that's a show stopper for me. For build bot maintenance, regression fixes, 
etc... being able to easily tell the number of commits between two revisions 
(in my head as opposed to using a tool) or the ordering of commits is crucial.

I think this is an interesting point. It seems there are two solutions. We can 
enforce fast-forward as many have pointed out and we can maintain an SVN 
mirror. Although I don't like the idea of maintaining an SVN repo, and it's 
almost universally agreed that git offers superior tools to SVN.



Then for everything else I use git and its power locally.



Right. Git clients are pretty nice.


- Ryosuke




___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Moving to Git?

2012-03-08 Thread Ashod Nakashian

 From: Geoffrey Garen gga...@apple.com
To: Ashod Nakashian ashodnakash...@yahoo.com 
Cc: WebKit Development webkit-dev@lists.webkit.org 
Sent: Thursday, March 8, 2012 9:22 PM
Subject: Re: [webkit-dev] Moving to Git?
 

Rather than asking for a switch to git by fiat, why not improve git and our 
git-related infrastructure to the point where people choose to switch 
naturally?


Switch by fiat? Not by a long shot. The call is to reevaluate the suggestion. 
Indeed, we must improve the infrastructure as long as there are users, 
regardless of any plans of moving VCs.


The fact that many valuable contributors choose not to use git is sufficient 
proof that switching by fiat would be a bad idea.

This is part of the goal - to see how many still use SVN, what's holding them 
back from the move and how we can help them and the community to make the 
transition to what is deemed by most (my estimate) to be superior.

On that count, what feature do you find in svn that is missing from git, or put 
differently, why is git not as good as svn for you? 




Geoff



On Mar 8, 2012, at 4:35 AM, Ashod Nakashian wrote:

WebKittens,


In the light of discovering that some SVN scripts have fallen behind in terms 
of maintenance[1] and WebKit's strong Git support and infrastructure, against 
my better judgement, I'd like to distract you from being productive by 
bringing up this topic (again).


The wiki page of the same name[2] was created 3 years ago and hardly updated 
since[3]. I know we're all busy with more important things, but IMHO I think 
we can at least update the wiki and perhaps vote on when/how we should do the 
eventual transition.


I understand that while this type of work isn't necessarily very productive, 
maintaining two repositories and sets of scripts (with their docs and issues) 
has a very real cost as well. I'm proposing we reevaluate the situation and 
act accordingly.


[1] https://bugs.webkit.org/show_bug.cgi?id=79509#c6

[2] http://trac.webkit.org/wiki/Moving%20to%20Git
[3] http://trac.webkit.org/wiki/Moving%20to%20Git?action=history


Thanks for lending an ear,
-Ash
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev




___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Moving to Git?

2012-03-08 Thread simon . hausmann
Alexis, imagine not pushing directly but going through an intermediate system 
like in Qt - where history is nicely linear now :)


Simon

From: webkit-dev-boun...@lists.webkit.org [webkit-dev-boun...@lists.webkit.org] 
on behalf of ext Alexis Menard [alexis.men...@openbossa.org]
Sent: Thursday, March 08, 2012 18:35
To: Konrad Piascik
Cc: webkit-dev@lists.webkit.org
Subject: Re: [webkit-dev] Moving to Git?

On Thu, Mar 8, 2012 at 2:32 PM, Konrad Piascik kpias...@rim.com wrote:
 It is possible to keep linear history with git.  This just requires you to 
 fast forward and rebase before pushing.

But can you enforce in the server? To avoid people to push it by mistake?

 Konrad
 Sent from my BlackBerry on the Rogers Wireless Network

 - Original Message -
 From: Carlos Garcia Campos [mailto:carlo...@webkit.org]
 Sent: Thursday, March 08, 2012 12:27 PM
 To: webkit-dev@lists.webkit.org webkit-dev@lists.webkit.org
 Subject: Re: [webkit-dev] Moving to Git?

 El jue, 08-03-2012 a las 14:10 -0300, Alexis Menard escribió:
 On Thu, Mar 8, 2012 at 2:03 PM, Ryosuke Niwa rn...@webkit.org wrote:
  On Thu, Mar 8, 2012 at 4:35 AM, Ashod Nakashian ashodnakash...@yahoo.com
  wrote:
 
  In the light of discovering that some SVN scripts have fallen behind in
  terms of maintenance[1] and WebKit's strong Git support and 
  infrastructure,
  against my better judgement, I'd like to distract you from being 
  productive
  by bringing up this topic (again).
 
  The wiki page of the same name[2] was created 3 years ago and hardly
  updated since[3]. I know we're all busy with more important things, but 
  IMHO
  I think we can at least update the wiki and perhaps vote on when/how we
  should do the eventual transition.
 
  I understand that while this type of work isn't necessarily very
  productive, maintaining two repositories and sets of scripts (with their
  docs and issues) has a very real cost as well. I'm proposing we reevaluate
  the situation and act accordingly.
 
 
  Re-evaluating the situation is good, but I'm still opposed.

 I don't use svn but the only benefit I see of WebKit using svn is the
 linear history, clean, easy to read and to explore. Git repos tend to
 have merging commits a lot and it leads to make bisecting/history
 browsing harder (my taste).

 I agree about merging commits, but I think it's possible to enforce all
 merges to be fast-forward and without merging commits. In general
 browsing git history is easier and cleaner than svn, and more important
 it's much faster (my taste :-P)

 Then for everything else I use git and its power locally.

 I would be more than happy with the switch :-)

 --
 Carlos Garcia Campos
 http://pgp.rediris.es:11371/pks/lookup?op=getsearch=0xF3D322D0EC4582C3

 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

 -
 This transmission (including any attachments) may contain confidential 
 information, privileged material (including material protected by the 
 solicitor-client or other applicable privileges), or constitute non-public 
 information. Any use of this information by anyone other than the intended 
 recipient is prohibited. If you have received this transmission in error, 
 please immediately reply to the sender and delete this information from your 
 system. Use, dissemination, distribution, or reproduction of this 
 transmission by unintended recipients is not authorized and may be unlawful.
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev



--
Alexis Menard (darktears)
Software Engineer
INdT Recife Brazil
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Moving to Git?

2012-03-08 Thread Ryosuke Niwa
On Thu, Mar 8, 2012 at 11:24 AM, Ashod Nakashian
ashodnakash...@yahoo.comwrote:

  And that's a show stopper for me. For build bot maintenance, regression
 fixes, etc... being able to easily tell the number of commits between two
 revisions (in my head as opposed to using a tool) or the ordering of
 commits is crucial.

 I think this is an interesting point. It seems there are two solutions. We
 can enforce fast-forward as many have pointed out and we can maintain an
 SVN mirror. Although I don't like the idea of maintaining an SVN repo, and
 it's almost universally agreed that git offers superior tools to SVN.


I don't think so. I like the simplicity of svn. While git client works
great, I always get frustrated by the complexity of having multiple
branches locally and the amount of work required to merge the remote
changes on the branch I'm working on.

- Ryosuke
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Moving to Git?

2012-03-08 Thread Adam Treat
There is nothing about git that forces you to have multiple branches locally.  
Good practice, yes, but nothing forcing it.  As for the difficulty of resolving 
conflicts between patches you've made locally and changes made on the shared 
repository since you started making your local patches... nothing about git 
makes this any harder.  Unless you have a lock based source control system 
you'll have to resolve conflicts.

From: webkit-dev-boun...@lists.webkit.org [webkit-dev-boun...@lists.webkit.org] 
on behalf of Ryosuke Niwa [rn...@webkit.org]
Sent: Thursday, March 08, 2012 3:00 PM
To: Ashod Nakashian
Cc: WebKit Development
Subject: Re: [webkit-dev] Moving to Git?

On Thu, Mar 8, 2012 at 11:24 AM, Ashod Nakashian 
ashodnakash...@yahoo.commailto:ashodnakash...@yahoo.com wrote:
And that's a show stopper for me. For build bot maintenance, regression fixes, 
etc... being able to easily tell the number of commits between two revisions 
(in my head as opposed to using a tool) or the ordering of commits is crucial.

I think this is an interesting point. It seems there are two solutions. We can 
enforce fast-forward as many have pointed out and we can maintain an SVN 
mirror. Although I don't like the idea of maintaining an SVN repo, and it's 
almost universally agreed that git offers superior tools to SVN.

I don't think so. I like the simplicity of svn. While git client works great, I 
always get frustrated by the complexity of having multiple branches locally and 
the amount of work required to merge the remote changes on the branch I'm 
working on.

- Ryosuke


-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Moving to Git?

2012-03-08 Thread Joe Mason
It seems to me that there's no need to use multiple local branches in git if 
you find it confusing - it's an additional feature, but I don't see anything 
that requires it.

What workflow do you have that requires you to have multiple branches locally 
in git, and how do you solve it in svn without using branches?

What precisely do you find difficult about merging remote changes, and how is 
the svn equivalent easier?

From: webkit-dev-boun...@lists.webkit.org [webkit-dev-boun...@lists.webkit.org] 
on behalf of Ryosuke Niwa [rn...@webkit.org]
Sent: Thursday, March 08, 2012 3:00 PM
To: Ashod Nakashian
Cc: WebKit Development
Subject: Re: [webkit-dev] Moving to Git?

On Thu, Mar 8, 2012 at 11:24 AM, Ashod Nakashian 
ashodnakash...@yahoo.commailto:ashodnakash...@yahoo.com wrote:
And that's a show stopper for me. For build bot maintenance, regression fixes, 
etc... being able to easily tell the number of commits between two revisions 
(in my head as opposed to using a tool) or the ordering of commits is crucial.

I think this is an interesting point. It seems there are two solutions. We can 
enforce fast-forward as many have pointed out and we can maintain an SVN 
mirror. Although I don't like the idea of maintaining an SVN repo, and it's 
almost universally agreed that git offers superior tools to SVN.

I don't think so. I like the simplicity of svn. While git client works great, I 
always get frustrated by the complexity of having multiple branches locally and 
the amount of work required to merge the remote changes on the branch I'm 
working on.

- Ryosuke


-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Moving to Git?

2012-03-08 Thread Ryosuke Niwa
On Thu, Mar 8, 2012 at 12:04 PM, Adam Treat atr...@rim.com wrote:

 There is nothing about git that forces you to have multiple branches
 locally.  Good practice, yes, but nothing forcing it.  As for the
 difficulty of resolving conflicts between patches you've made locally and
 changes made on the shared repository since you started making your local
 patches... nothing about git makes this any harder.  Unless you have a lock
 based source control system you'll have to resolve conflicts.


On Thu, Mar 8, 2012 at 12:05 PM, Joe Mason jma...@rim.com wrote:

 It seems to me that there's no need to use multiple local branches in git
 if you find it confusing - it's an additional feature, but I don't see
 anything that requires it.

 What workflow do you have that requires you to have multiple branches
 locally in git, and how do you solve it in svn without using branches?

 What precisely do you find difficult about merging remote changes, and how
 is the svn equivalent easier?


The simplicity. In git, I have to worry about things like committing local
changes before rebasing to master, or stashing, etc... In svn, all I have
to do is to run svn up.

- Ryosuke
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Moving to Git?

2012-03-08 Thread Antonio Gomes
(For those valuable contributors who are against Git and have manifested
somehow here, please do not take it personally)

IMO, none of the arguments used here so far seem like a real problem for a
switch. Of course, SVN people would have to adapt their workflow and it
could take days (no more than that, trust me), but it is for a greater goal
at the end.

In my opinion, SVN concepts are completely obsolete these days. It is hard
to me to even hear someone arguing in favor of SVN against GIT, but I
respect anyone's opinion. I just do not feel them strong enough given the
whole context.

On Thu, Mar 8, 2012 at 3:05 PM, Joe Mason jma...@rim.com wrote:

 It seems to me that there's no need to use multiple local branches in git
 if you find it confusing - it's an additional feature, but I don't see
 anything that requires it.

 What workflow do you have that requires you to have multiple branches
 locally in git, and how do you solve it in svn without using branches?

 What precisely do you find difficult about merging remote changes, and how
 is the svn equivalent easier?
 
 From: webkit-dev-boun...@lists.webkit.org [
 webkit-dev-boun...@lists.webkit.org] on behalf of Ryosuke Niwa [
 rn...@webkit.org]
 Sent: Thursday, March 08, 2012 3:00 PM
 To: Ashod Nakashian
 Cc: WebKit Development
 Subject: Re: [webkit-dev] Moving to Git?

 On Thu, Mar 8, 2012 at 11:24 AM, Ashod Nakashian ashodnakash...@yahoo.com
 mailto:ashodnakash...@yahoo.com wrote:
 And that's a show stopper for me. For build bot maintenance, regression
 fixes, etc... being able to easily tell the number of commits between two
 revisions (in my head as opposed to using a tool) or the ordering of
 commits is crucial.

 I think this is an interesting point. It seems there are two solutions. We
 can enforce fast-forward as many have pointed out and we can maintain an
 SVN mirror. Although I don't like the idea of maintaining an SVN repo, and
 it's almost universally agreed that git offers superior tools to SVN.

 I don't think so. I like the simplicity of svn. While git client works
 great, I always get frustrated by the complexity of having multiple
 branches locally and the amount of work required to merge the remote
 changes on the branch I'm working on.

 - Ryosuke


 -
 This transmission (including any attachments) may contain confidential
 information, privileged material (including material protected by the
 solicitor-client or other applicable privileges), or constitute non-public
 information. Any use of this information by anyone other than the intended
 recipient is prohibited. If you have received this transmission in error,
 please immediately reply to the sender and delete this information from
 your system. Use, dissemination, distribution, or reproduction of this
 transmission by unintended recipients is not authorized and may be unlawful.
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev




-- 
--Antonio Gomes
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Moving to Git?

2012-03-08 Thread Dirk Pranke
On Thu, Mar 8, 2012 at 9:22 AM, Geoffrey Garen gga...@apple.com wrote:
 Rather than asking for a switch to git by fiat, why not improve git and our
 git-related infrastructure to the point where people choose to switch
 naturally?

 The fact that many valuable contributors choose not to use git is sufficient
 proof that switching by fiat would be a bad idea.


People have been improving our git infrastructure constantly; I think
the point is the converse ... it's getting harder to support SVN, and
supporting two systems does impose a cost (at least to the people like
me that do hack on the infrastructure :).

That said, I have to agree that it's nice to be able to see a
monotonically increasing number in the change history. Even if you
have a single linear branch in the git master, you don't have that.
Maybe there is a practice for getting an equivalent using labels or
tags in git repos that I don't know about?

-- Dirk
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Moving to Git?

2012-03-08 Thread Geoffrey Garen
 IMO, none of the arguments used here so far seem like a real problem for a 
 switch. Of course, SVN people would have to adapt their workflow and it could 
 take days (no more than that, trust me), but it is for a greater goal at the 
 end.

This is an example of what I mean by fiat:

Step 1: Force a change upon people
Step 2: …
Step 3: A greater good is achieved

Geoff___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Moving to Git?

2012-03-08 Thread Antonio Gomes
Hi Geoff. I might have missed your point. Who is trying to force you to
change something?

I would love to understand the other side for sure...

On Thu, Mar 8, 2012 at 3:20 PM, Geoffrey Garen gga...@apple.com wrote:

 IMO, none of the arguments used here so far seem like a real problem for a
 switch. Of course, SVN people would have to adapt their workflow and it
 could take days (no more than that, trust me), but it is for a greater goal
 at the end.


 This is an example of what I mean by fiat:

 Step 1: Force a change upon people
 Step 2: …
 Step 3: A greater good is achieved

 Geoff




-- 
--Antonio Gomes
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Moving to Git?

2012-03-08 Thread Jochen Eisinger
On Thu, Mar 8, 2012 at 9:12 PM, Ryosuke Niwa rn...@webkit.org wrote:

 On Thu, Mar 8, 2012 at 12:04 PM, Adam Treat atr...@rim.com wrote:

 There is nothing about git that forces you to have multiple branches
 locally.  Good practice, yes, but nothing forcing it.  As for the
 difficulty of resolving conflicts between patches you've made locally and
 changes made on the shared repository since you started making your local
 patches... nothing about git makes this any harder.  Unless you have a lock
 based source control system you'll have to resolve conflicts.


 On Thu, Mar 8, 2012 at 12:05 PM, Joe Mason jma...@rim.com wrote:

 It seems to me that there's no need to use multiple local branches in git
 if you find it confusing - it's an additional feature, but I don't see
 anything that requires it.

 What workflow do you have that requires you to have multiple branches
 locally in git, and how do you solve it in svn without using branches?

 What precisely do you find difficult about merging remote changes, and
 how is the svn equivalent easier?


 The simplicity. In git, I have to worry about things like committing local
 changes before rebasing to master, or stashing, etc... In svn, all I have
 to do is to run svn up.


I wonder, do you really run svn up that much? I'd expect that this breaks
your checkout every now and then if some dependencies change. I usually run
update-webkit, which should hide the rebasing actions from you

-jochen


 - Ryosuke


 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Moving to Git?

2012-03-08 Thread Hugo Parente Lima
On Thursday 08 March 2012 17:12:47 Ryosuke Niwa wrote:
 On Thu, Mar 8, 2012 at 12:04 PM, Adam Treat atr...@rim.com wrote:
  There is nothing about git that forces you to have multiple branches
  locally.  Good practice, yes, but nothing forcing it.  As for the
  difficulty of resolving conflicts between patches you've made locally and
  changes made on the shared repository since you started making your local
  patches... nothing about git makes this any harder.  Unless you have a
  lock based source control system you'll have to resolve conflicts.
 
 On Thu, Mar 8, 2012 at 12:05 PM, Joe Mason jma...@rim.com wrote:
  It seems to me that there's no need to use multiple local branches in git
  if you find it confusing - it's an additional feature, but I don't see
  anything that requires it.
  
  What workflow do you have that requires you to have multiple branches
  locally in git, and how do you solve it in svn without using branches?
  
  What precisely do you find difficult about merging remote changes, and
  how is the svn equivalent easier?
 
 The simplicity. In git, I have to worry about things like committing local
 changes before rebasing to master, or stashing, etc... In svn, all I have
 to do is to run svn up.

git pull does the same (if no conflicts were found, but the same pain will 
happen on svn in case of conflicts)
 
or git fetch origin; git rebase origin/master

I remember the days were I switched from svn to git, blaming git for force me 
to type additional commands, today I'm just regrets for the blames and can't 
think in another VCS than git :-). 

 - Ryosuke

-- 
Hugo Parente Lima
INdT - Instituto Nokia de Tecnologia


signature.asc
Description: This is a digitally signed message part.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Moving to Git?

2012-03-08 Thread Joe Mason
Well, not quite. The equivalent to svn up is git pull --rebase 
origin/master (which should be the default, as git merge is the bit that 
horribly confuses people - but I digress).  I'm not sure if it will fill in the 
origin/master part automatically.

What Ryosuke seems to be complaining about is that if you have changes to your 
working copy, svn up will automatically merge them, which could lead to 
conflicts you have to untangle, while git pull --rebase will give an error 
telling you you must commit or stash them first.  So the real equivalent to 
svn up is git stash  git pull --rebase origin/master  git stash pop.  
And git stash pop will start pretty much the same merging process as svn's if 
there are conflicts.

This is only slightly more complicated, and has the benefit that if something 
goes wrong, your changes remain explicitly in the git stash, where you can get 
at them with commands like git stash show or git stash branch, whereas 
unless svn has features I don't know about, if svn up does unexpected things 
the only record of your changes is a series of conflict markers you'll need to 
resolve.

And you can always make a git-up script that does git stash  git pull 
--rebase origin/master  git stash pop, so the command you type won't even be 
any longer than svn up, but will give you more safety.

From: webkit-dev-boun...@lists.webkit.org [webkit-dev-boun...@lists.webkit.org] 
on behalf of Hugo Parente Lima [hugo.l...@openbossa.org]
Sent: Thursday, March 08, 2012 3:45 PM
To: webkit-dev@lists.webkit.org
Subject: Re: [webkit-dev] Moving to Git?

On Thursday 08 March 2012 17:12:47 Ryosuke Niwa wrote:
 On Thu, Mar 8, 2012 at 12:04 PM, Adam Treat atr...@rim.com wrote:
  There is nothing about git that forces you to have multiple branches
  locally.  Good practice, yes, but nothing forcing it.  As for the
  difficulty of resolving conflicts between patches you've made locally and
  changes made on the shared repository since you started making your local
  patches... nothing about git makes this any harder.  Unless you have a
  lock based source control system you'll have to resolve conflicts.

 On Thu, Mar 8, 2012 at 12:05 PM, Joe Mason jma...@rim.com wrote:
  It seems to me that there's no need to use multiple local branches in git
  if you find it confusing - it's an additional feature, but I don't see
  anything that requires it.
 
  What workflow do you have that requires you to have multiple branches
  locally in git, and how do you solve it in svn without using branches?
 
  What precisely do you find difficult about merging remote changes, and
  how is the svn equivalent easier?

 The simplicity. In git, I have to worry about things like committing local
 changes before rebasing to master, or stashing, etc... In svn, all I have
 to do is to run svn up.

git pull does the same (if no conflicts were found, but the same pain will
happen on svn in case of conflicts)

or git fetch origin; git rebase origin/master

I remember the days were I switched from svn to git, blaming git for force me
to type additional commands, today I'm just regrets for the blames and can't
think in another VCS than git :-).

 - Ryosuke

--
Hugo Parente Lima
INdT - Instituto Nokia de Tecnologia

-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Moving to Git?

2012-03-08 Thread Ryosuke Niwa
On Thu, Mar 8, 2012 at 12:44 PM, Jochen Eisinger joc...@chromium.org
 wrote:

 On Thu, Mar 8, 2012 at 9:12 PM, Ryosuke Niwa rn...@webkit.org wrote:

 The simplicity. In git, I have to worry about things like committing
 local changes before rebasing to master, or stashing, etc... In svn, all I
 have to do is to run svn up.


 I wonder, do you really run svn up that much? I'd expect that this breaks
 your checkout every now and then if some dependencies change. I usually run
 update-webkit, which should hide the rebasing actions from you


I do that at least 5-6 times a day if not more.

On Thu, Mar 8, 2012 at 12:58 PM, John Yani van...@gmail.com wrote:

  I don't think so. I like the simplicity of svn. While git client works
  great, I always get frustrated by the complexity of having multiple
 branches
  locally and the amount of work required to merge the remote changes on
 the
  branch I'm working on.

 What do you mean?

 # fetch from origin master and merge into the current branch
 git pull origin master


Huh? That's not equivalent to svn up at all.

On Thu, Mar 8, 2012 at 1:19 PM, Joe Mason jma...@rim.com wrote:

 What Ryosuke seems to be complaining about is that if you have changes to
 your working copy, svn up will automatically merge them, which could lead
 to conflicts you have to untangle, while git pull --rebase will give an
 error telling you you must commit or stash them first.  So the real
 equivalent to svn up is git stash  git pull --rebase origin/master 
 git stash pop.  And git stash pop will start pretty much the same
 merging process as svn's if there are conflicts.


Right. But I can't bother to type that much myself. Maybe my complain will
go away if someone had implemented webkit-patch up that does this
automatically.

This is only slightly more complicated


I'd say astoundingly more complicated because of

and has the benefit that if something goes wrong, your changes remain
 explicitly in the git stash, where you can get at them with commands like
 git stash show or git stash branch



 whereas unless svn has features I don't know about, if svn up does
 unexpected things the only record of your changes is a series of conflict
 markers you'll need to resolve.


But I can just run svn diff to create a backup if I really wanted to save
the original change. But I've never had a trouble merging things so it's
hard for me to tell if that's really useful or not.

And you can always make a git-up script that does git stash  git pull
 --rebase origin/master  git stash pop, so the command you type won't
 even be any longer than svn up, but will give you more safety.


That'll certainly be an improvement. I still dislike git hashes though. If
someone implements such a script in webkit-patch and we can automatically
assign svn-revision like numbers to all commits, I can be convinced to use
git.

- Ryosuke
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Moving to Git?

2012-03-08 Thread Joe Mason
I agree that git's hashes are less friendly than the monotonically increasing 
commit numbers from svn or p4.  I've occasionally been given a pair of git 
hashes and had no idea which one came first, or even if they were in the same 
branch.

git log --oneline hash is a pretty simple way to list all the commits 
coming before the given hash, so you can see the order of them.  Other than 
that, maybe a post-commit hook that automatically puts a

Aside: here's a neat command to map git hash's to svn-style ascending numbers: 
git log --oneline hash|cat -b

$ git log --oneline e865bb0|cat -b|head
 1  e865bb0 [Qt WK2] Remove duplicate code related to dialog handling in 
QQuickWebView https://bugs.webkit.org/show_bug.cgi?id=80557
 2  a6b3dd6 Fix flaky test by decreasing granularity of cues (cues cover 
longer time intervals). The flakiness seems to appear because the video is 
paused synchronously, while missed events events are dispatched asynchronously.
 3  9e20583 [Qt] Rebaseline after r110072.
 4  4e072d9 [Qt] Windows build fix.ommit
 5  7c7ab53 [chromium] Unreviewed gardening.
 6  7c004bc Web Inspector: The function had to return a hash but it 
returned just address. https://bugs.webkit.org/show_bug.cgi?id=80591
 7  d4c2667 Unreviewed single line fix. The function had to return a hash 
but it returned just address.
 8  7b5de0b [chromium] Unreviewed gardening.
 9  5540031 shadow should be rendered correctly. 
https://bugs.webkit.org/show_bug.cgi?id=78596
10  9040697 Speech JavaScript API: SpeechRecognitionAlternative, Result and 
ResultList https://bugs.webkit.org/show_bug.cgi?id=80424

...except of course that this is descending numbers (1 is the most recent) and 
they're not persistent, so telling somebody commit 8 only works if they're 
starting from the same point.  Which makes them not incredibly useful.


From: ryosuke.n...@gmail.com [ryosuke.n...@gmail.com] on behalf of Ryosuke Niwa 
[rn...@webkit.org]
Sent: Thursday, March 08, 2012 4:25 PM
To: Joe Mason
Cc: Hugo Parente Lima; webkit-dev@lists.webkit.org
Subject: Re: [webkit-dev] Moving to Git?

On Thu, Mar 8, 2012 at 12:44 PM, Jochen Eisinger 
joc...@chromium.orgmailto:joc...@chromium.org wrote:
On Thu, Mar 8, 2012 at 9:12 PM, Ryosuke Niwa 
rn...@webkit.orgmailto:rn...@webkit.org wrote:
The simplicity. In git, I have to worry about things like committing local 
changes before rebasing to master, or stashing, etc... In svn, all I have to do 
is to run svn up.

I wonder, do you really run svn up that much? I'd expect that this breaks your 
checkout every now and then if some dependencies change. I usually run 
update-webkit, which should hide the rebasing actions from you

I do that at least 5-6 times a day if not more.

On Thu, Mar 8, 2012 at 12:58 PM, John Yani 
van...@gmail.commailto:van...@gmail.com wrote:
 I don't think so. I like the simplicity of svn. While git client works
 great, I always get frustrated by the complexity of having multiple branches
 locally and the amount of work required to merge the remote changes on the
 branch I'm working on.

What do you mean?

# fetch from origin master and merge into the current branch
git pull origin mtaster

Huh? That's not equivalent to svn up at all.

On Thu, Mar 8, 2012 at 1:19 PM, Joe Mason 
jma...@rim.commailto:jma...@rim.com wrote:
What Ryosuke seems to be complaining about is that if you have changes to your 
working copy, svn up will automatically merge them, which could lead to 
conflicts you have to untangle, while git pull --rebase will give an error 
telling you you must commit or stash them first.  So the real equivalent to 
svn up is git stash  git pull --rebase origin/master  git stash pop.  
And git stash pop will start pretty much the same merging process as svn's if 
there are conflicts.

Right. But I can't bother to type that much myself. Maybe my complain will go 
away if someone had implemented webkit-patch up that does this automatically.

This is only slightly more complicated

I'd say astoundingly more complicated because of

and has the benefit that if something goes wrong, your changes remain 
explicitly in the git stash, where you can get at them with commands like git 
stash show or git stash branch

whereas unless svn has features I don't know about, if svn up does unexpected 
things the only record of your changes is a series of conflict markers you'll 
need to resolve.

But I can just run svn diff to create a backup if I really wanted to save the 
original change. But I've never had a trouble merging things so it's hard for 
me to tell if that's really useful or not.

And you can always make a git-up script that does git stash  git pull 
--rebase origin/master  git stash pop, so the command you type won't even be 
any longer than svn up, but will give you more safety.

That'll certainly be an improvement. I still dislike git hashes though. If 
someone implements such a script in webkit-patch and we

Re: [webkit-dev] Moving to Git?

2012-03-08 Thread Maciej Stachowiak

It seems like there are a couple of different issues here that affect how we do 
version control. Currently we have an SVN primary repository, some contributors 
use SVN, and others use git via git-svn.

It seems like there are two possible changes we can make, and it is not really 
clear to me which is being advocated:

1) Offer only a git repository; everyone uses git.
2) Use a git central repository; but some form of svn access is provided (is 
this even possible?)

And then there is the status quo:

3) Continue doing what we're doing; central repository is svn, but anyone is 
free to use git and we try to make it convenient to do so.

One interesting asymmetry here is that, while many git users proseltyze git and 
advocate total removal of svn support from our tools and infrastructure, no one 
seems to advocate completely removing git support. So I left that option off. 
There are also other distributed version control systems out there such as 
Mercurial or Bazaar, but no one seems much in favor of using them for WebKit, 
so those options are also left off.

If we are to assess these options in a deeper way than just everyone saying 
what they personally like, we need to identify the pros and cons of options (1) 
and (2) relative to (3). That's assuming (2) is even possible. It seems like 
there are at least a few factors to consider:

A) Future quality of life for current git users.
B) Future quality of life for current svn users.
C) Benefits of the master repository being either git or svn, regardless of 
what clients are supported. (For example, many folks seem to think 
human-understandable revision identifiers is a benefit of the master being SVN).
D) Cost to the project of maintaining support for two different version control 
systems.

Git advocates on this thread have mostly focused on convincing svn users how 
much they'd like using git instead. It seems at least some svn users do not 
believe their quality of life would improve by switching to git, including some 
who have actually tried git. No one has really identified what benefits there 
would be to git users if a change is made. Could someone describe those?

Regards,
Maciej


On Mar 8, 2012, at 12:13 PM, Antonio Gomes wrote:

 (For those valuable contributors who are against Git and have manifested 
 somehow here, please do not take it personally)
 
 IMO, none of the arguments used here so far seem like a real problem for a 
 switch. Of course, SVN people would have to adapt their workflow and it could 
 take days (no more than that, trust me), but it is for a greater goal at the 
 end.
 
 In my opinion, SVN concepts are completely obsolete these days. It is hard to 
 me to even hear someone arguing in favor of SVN against GIT, but I respect 
 anyone's opinion. I just do not feel them strong enough given the whole 
 context.
 
 On Thu, Mar 8, 2012 at 3:05 PM, Joe Mason jma...@rim.com wrote:
 It seems to me that there's no need to use multiple local branches in git if 
 you find it confusing - it's an additional feature, but I don't see anything 
 that requires it.
 
 What workflow do you have that requires you to have multiple branches locally 
 in git, and how do you solve it in svn without using branches?
 
 What precisely do you find difficult about merging remote changes, and how is 
 the svn equivalent easier?
 
 From: webkit-dev-boun...@lists.webkit.org 
 [webkit-dev-boun...@lists.webkit.org] on behalf of Ryosuke Niwa 
 [rn...@webkit.org]
 Sent: Thursday, March 08, 2012 3:00 PM
 To: Ashod Nakashian
 Cc: WebKit Development
 Subject: Re: [webkit-dev] Moving to Git?
 
 On Thu, Mar 8, 2012 at 11:24 AM, Ashod Nakashian 
 ashodnakash...@yahoo.commailto:ashodnakash...@yahoo.com wrote:
 And that's a show stopper for me. For build bot maintenance, regression 
 fixes, etc... being able to easily tell the number of commits between two 
 revisions (in my head as opposed to using a tool) or the ordering of commits 
 is crucial.
 
 I think this is an interesting point. It seems there are two solutions. We 
 can enforce fast-forward as many have pointed out and we can maintain an SVN 
 mirror. Although I don't like the idea of maintaining an SVN repo, and it's 
 almost universally agreed that git offers superior tools to SVN.
 
 I don't think so. I like the simplicity of svn. While git client works great, 
 I always get frustrated by the complexity of having multiple branches locally 
 and the amount of work required to merge the remote changes on the branch I'm 
 working on.
 
 - Ryosuke
 
 
 -
 This transmission (including any attachments) may contain confidential 
 information, privileged material (including material protected by the 
 solicitor-client or other applicable privileges), or constitute non-public 
 information. Any use of this information by anyone other than the intended 
 recipient is prohibited. If you have received

Re: [webkit-dev] Moving to Git?

2012-03-08 Thread Dirk Pranke
On Thu, Mar 8, 2012 at 2:10 PM, Maciej Stachowiak m...@apple.com wrote:

 It seems like there are a couple of different issues here that affect how we
 do version control. Currently we have an SVN primary repository, some
 contributors use SVN, and others use git via git-svn.

 It seems like there are two possible changes we can make, and it is not
 really clear to me which is being advocated:

 1) Offer only a git repository; everyone uses git.
 2) Use a git central repository; but some form of svn access is provided (is
 this even possible?)

There appear to be scripts on the interweb that would allow access to
a git repo over svn. I would be against doing this here (if we're
going to allow svn access at all, we might as well stay with what we
have).

I believe that a git repo would allow slightly easier cloning and
branching, and would make the overall system more reliable (because we
wouldn't have to worry about the git/svn bridge breaking or getting
corrupted).

I don't think either of these reasons is particularly compelling,
although I have no real insight into the uptime / ops costs of keeping
the two repos in sync vs. only a git repo.

I think the major benefit in moving git-only would be to simplify the
tooling and the documentation for the project (we wouldn't have to
document how to access everything two or three different ways). I am
uncertain but skeptical that the tooling benefit outweighs the cost of
the conversion.

-- Dirk
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Moving to Git?

2012-03-08 Thread Alexis Menard
On Thu, Mar 8, 2012 at 7:10 PM, Maciej Stachowiak m...@apple.com wrote:

 It seems like there are a couple of different issues here that affect how we
 do version control. Currently we have an SVN primary repository, some
 contributors use SVN, and others use git via git-svn.

 It seems like there are two possible changes we can make, and it is not
 really clear to me which is being advocated:

 1) Offer only a git repository; everyone uses git.
 2) Use a git central repository; but some form of svn access is provided (is
 this even possible?)

 And then there is the status quo:

 3) Continue doing what we're doing; central repository is svn, but anyone is
 free to use git and we try to make it convenient to do so.

 One interesting asymmetry here is that, while many git users proseltyze git
 and advocate total removal of svn support from our tools and infrastructure,
 no one seems to advocate completely removing git support. So I left that
 option off. There are also other distributed version control systems out
 there such as Mercurial or Bazaar, but no one seems much in favor of using
 them for WebKit, so those options are also left off.

 If we are to assess these options in a deeper way than just everyone saying
 what they personally like, we need to identify the pros and cons of options
 (1) and (2) relative to (3). That's assuming (2) is even possible. It seems
 like there are at least a few factors to consider:

 A) Future quality of life for current git users.
 B) Future quality of life for current svn users.
 C) Benefits of the master repository being either git or svn, regardless of
 what clients are supported. (For example, many folks seem to think
 human-understandable revision identifiers is a benefit of the master being
 SVN).
 D) Cost to the project of maintaining support for two different version
 control systems.

 Git advocates on this thread have mostly focused on convincing svn users how
 much they'd like using git instead. It seems at least some svn users do not
 believe their quality of life would improve by switching to git, including
 some who have actually tried git. No one has really identified what benefits
 there would be to git users if a change is made. Could someone describe
 those?

To the global infrastructure :
- Local history for git. svn log access to the server every time you
call that command. Will improve the load of the server.
- Performance of checkouts/pull as data are send compressed from the server.

To git user :
- Using git push rather than having to use git-svn (which you need to
keep in sync).
- Simplified workflow, we don't need to mess with git-svn.
- Companies who fork (we all do) can simplify their workflow a bit
regarding branches.

To svn user :
- Conflict resolving much easier and performant than svn (we have
drivers for changelogs and the default one are much better than svn).
- Local history/blaming/...
- Proper diff coloration (though I'm sure you guys have some magic
scripts using colordiff).
- The staging area, upload what you want/need and keep some work local
- Smaller checkouts

The real downside is for the svn users to learn a bit git workflow.

I'm forgetting stuff for sure.


 Regards,
 Maciej


 On Mar 8, 2012, at 12:13 PM, Antonio Gomes wrote:

 (For those valuable contributors who are against Git and have manifested
 somehow here, please do not take it personally)

 IMO, none of the arguments used here so far seem like a real problem for a
 switch. Of course, SVN people would have to adapt their workflow and it
 could take days (no more than that, trust me), but it is for a greater goal
 at the end.

 In my opinion, SVN concepts are completely obsolete these days. It is hard
 to me to even hear someone arguing in favor of SVN against GIT, but I
 respect anyone's opinion. I just do not feel them strong enough given the
 whole context.

 On Thu, Mar 8, 2012 at 3:05 PM, Joe Mason jma...@rim.com wrote:

 It seems to me that there's no need to use multiple local branches in git
 if you find it confusing - it's an additional feature, but I don't see
 anything that requires it.

 What workflow do you have that requires you to have multiple branches
 locally in git, and how do you solve it in svn without using branches?

 What precisely do you find difficult about merging remote changes, and how
 is the svn equivalent easier?
 
 From: webkit-dev-boun...@lists.webkit.org
 [webkit-dev-boun...@lists.webkit.org] on behalf of Ryosuke Niwa
 [rn...@webkit.org]
 Sent: Thursday, March 08, 2012 3:00 PM
 To: Ashod Nakashian
 Cc: WebKit Development
 Subject: Re: [webkit-dev] Moving to Git?

 On Thu, Mar 8, 2012 at 11:24 AM, Ashod Nakashian
 ashodnakash...@yahoo.commailto:ashodnakash...@yahoo.com wrote:
 And that's a show stopper for me. For build bot maintenance, regression
  fixes, etc... being able to easily tell the number of commits between two
  revisions (in my head as opposed to using a tool) or the ordering

Re: [webkit-dev] Moving to Git?

2012-03-08 Thread David Barr
On Fri, Mar 9, 2012 at 8:25 AM, Ryosuke Niwa rn...@webkit.org wrote:

 On Thu, Mar 8, 2012 at 1:19 PM, Joe Mason jma...@rim.com wrote:

 What Ryosuke seems to be complaining about is that if you have changes to
 your working copy, svn up will automatically merge them, which could lead
 to conflicts you have to untangle, while git pull --rebase will give an
 error telling you you must commit or stash them first.  So the real
 equivalent to svn up is git stash  git pull --rebase origin/master 
 git stash pop.  And git stash pop will start pretty much the same merging
 process as svn's if there are conflicts.


 Right. But I can't bother to type that much myself. Maybe my complain will
 go away if someone had implemented webkit-patch up that does this
 automatically.

 And you can always make a git-up script that does git stash  git pull
 --rebase origin/master  git stash pop, so the command you type won't even
 be any longer than svn up, but will give you more safety.


 That'll certainly be an improvement. I still dislike git hashes though. If
 someone implements such a script in webkit-patch and we can automatically
 assign svn-revision like numbers to all commits, I can be convinced to use
 git.

I fully support scripts specific to the WebKit workflow that wrap the
VCS specifics.

In my former role, I spoke to developers to identify their most common
sequences of actions when synchronising their code and what
information they needed when a step failed.
I then wrote a common script that would execute as much of the process
as it could and provide information and instruction on failure.
This was a boon to productivity as in the common case, synchronisation
was sub-second, and in the uncommon case they no longer had to dig up
the relevant information before resolving conflicts.

I think we ought to streamline the git workflow before we start trying
to proselytise Subversion users. :)

The monotonic labels that Ryosuke desires are known in git language as
generation numbers. If we maintain a canonical linear history going
forward, they would also be unique as with Subversion. This could be a
good reason to resurrect the relevant thread on the git mailing list.

--
David Barr.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Moving to Git?

2012-03-08 Thread Alexis Menard
 Cc: WebKit Development
 Subject: Re: [webkit-dev] Moving to Git?

 On Thu, Mar 8, 2012 at 11:24 AM, Ashod Nakashian
 ashodnakash...@yahoo.commailto:ashodnakash...@yahoo.com wrote:
 And that's a show stopper for me. For build bot maintenance, regression
  fixes, etc... being able to easily tell the number of commits between two
  revisions (in my head as opposed to using a tool) or the ordering of 
  commits
  is crucial.

 I think this is an interesting point. It seems there are two solutions. We
 can enforce fast-forward as many have pointed out and we can maintain an SVN
 mirror. Although I don't like the idea of maintaining an SVN repo, and it's
 almost universally agreed that git offers superior tools to SVN.

 I don't think so. I like the simplicity of svn. While git client works
 great, I always get frustrated by the complexity of having multiple branches
 locally and the amount of work required to merge the remote changes on the
 branch I'm working on.

 - Ryosuke


 -
 This transmission (including any attachments) may contain confidential
 information, privileged material (including material protected by the
 solicitor-client or other applicable privileges), or constitute non-public
 information. Any use of this information by anyone other than the intended
 recipient is prohibited. If you have received this transmission in error,
 please immediately reply to the sender and delete this information from your
 system. Use, dissemination, distribution, or reproduction of this
 transmission by unintended recipients is not authorized and may be unlawful.
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev




 --
 --Antonio Gomes
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev



 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev




 --
 Alexis Menard (darktears)
 Software Engineer
 INdT Recife Brazil



-- 
Alexis Menard (darktears)
Software Engineer
INdT Recife Brazil
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Moving to Git?

2012-03-08 Thread Patrick Gansterer

Am 08.03.2012 um 23:30 schrieb Alexis Menard:

 On Thu, Mar 8, 2012 at 7:10 PM, Maciej Stachowiak m...@apple.com wrote:
 
 It seems like there are a couple of different issues here that affect how we
 do version control. Currently we have an SVN primary repository, some
 contributors use SVN, and others use git via git-svn.
 
 It seems like there are two possible changes we can make, and it is not
 really clear to me which is being advocated:
 
 1) Offer only a git repository; everyone uses git.
 2) Use a git central repository; but some form of svn access is provided (is
 this even possible?)
 
 And then there is the status quo:
 
 3) Continue doing what we're doing; central repository is svn, but anyone is
 free to use git and we try to make it convenient to do so.
 
 One interesting asymmetry here is that, while many git users proseltyze git
 and advocate total removal of svn support from our tools and infrastructure,
 no one seems to advocate completely removing git support. So I left that
 option off. There are also other distributed version control systems out
 there such as Mercurial or Bazaar, but no one seems much in favor of using
 them for WebKit, so those options are also left off.
 
 If we are to assess these options in a deeper way than just everyone saying
 what they personally like, we need to identify the pros and cons of options
 (1) and (2) relative to (3). That's assuming (2) is even possible. It seems
 like there are at least a few factors to consider:
 
 A) Future quality of life for current git users.
 B) Future quality of life for current svn users.
 C) Benefits of the master repository being either git or svn, regardless of
 what clients are supported. (For example, many folks seem to think
 human-understandable revision identifiers is a benefit of the master being
 SVN).
 D) Cost to the project of maintaining support for two different version
 control systems.
 
 Git advocates on this thread have mostly focused on convincing svn users how
 much they'd like using git instead. It seems at least some svn users do not
 believe their quality of life would improve by switching to git, including
 some who have actually tried git. No one has really identified what benefits
 there would be to git users if a change is made. Could someone describe
 those?
 
 To the global infrastructure :
 - Local history for git. svn log access to the server every time you
 call that command. Will improve the load of the server.
 - Performance of checkouts/pull as data are send compressed from the server.

*) Easier way to setup local mirrors (for buildbots). See discussion at 
https://lists.webkit.org/pipermail/webkit-dev/2012-March/019699.html

 
 To git user :
 - Using git push rather than having to use git-svn (which you need to
 keep in sync).
 - Simplified workflow, we don't need to mess with git-svn.
 - Companies who fork (we all do) can simplify their workflow a bit
 regarding branches.
 
 To svn user :
 - Conflict resolving much easier and performant than svn (we have
 drivers for changelogs and the default one are much better than svn).
 - Local history/blaming/...
 - Proper diff coloration (though I'm sure you guys have some magic
 scripts using colordiff).
 - The staging area, upload what you want/need and keep some work local
 - Smaller checkouts
 
 The real downside is for the svn users to learn a bit git workflow.
 
 I'm forgetting stuff for sure.

- Patrick
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Moving to Git?

2012-03-08 Thread Dirk Pranke
On Thu, Mar 8, 2012 at 2:37 PM, David Barr davidb...@google.com wrote:
 The monotonic labels that Ryosuke desires are known in git language as
 generation numbers. If we maintain a canonical linear history going
 forward, they would also be unique as with Subversion. This could be a
 good reason to resurrect the relevant thread on the git mailing list.


slightly-offtopic, but I had not heard of generation numbers before.
Based on a cursory web-learning pass (*), it sounds like they're not
quite the same thing as SVN revisions, since SVN revision numers are
unique to a repo, and two revisions on two different branches may have
the same generation number. Since we do actually keep branches in the
master repo, this wouldn't quite be the same  (although it might
possibly be acceptable). Please correct me if I'm wrong ...

-- Dirk

(*) http://stackoverflow.com/questions/6702821/git-commit-generation-numbers
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Moving to Git?

2012-03-08 Thread Aaron Boodman
I think it would look the same, except for instead of monotonically
increasing decimal numbers in the revision column, you'd see random
hexadecimal ones (typically 6-8 digits long).

On Thu, Mar 8, 2012 at 4:20 PM, Lucas Forschler lforsch...@apple.com wrote:
 Could someone enlighten me on what this page would look like after a 
 conversion to git?

 http://build.webkit.org/builders/Windows%20Debug%20%28Build%29?numbuilds=100

 Lucas

 On Mar 8, 2012, at 3:22 PM, Dirk Pranke wrote:

 On Thu, Mar 8, 2012 at 2:37 PM, David Barr davidb...@google.com wrote:
 The monotonic labels that Ryosuke desires are known in git language as
 generation numbers. If we maintain a canonical linear history going
 forward, they would also be unique as with Subversion. This could be a
 good reason to resurrect the relevant thread on the git mailing list.


 slightly-offtopic, but I had not heard of generation numbers before.
 Based on a cursory web-learning pass (*), it sounds like they're not
 quite the same thing as SVN revisions, since SVN revision numers are
 unique to a repo, and two revisions on two different branches may have
 the same generation number. Since we do actually keep branches in the
 master repo, this wouldn't quite be the same  (although it might
 possibly be acceptable). Please correct me if I'm wrong ...

 -- Dirk

 (*) http://stackoverflow.com/questions/6702821/git-commit-generation-numbers
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev