Re: git (yet again)

2014-09-04 Thread Martin Grigorov
On Thu, Sep 4, 2014 at 12:46 AM, sebb seb...@gmail.com wrote:

 On 3 September 2014 16:10, Martin Grigorov mgrigo...@apache.org wrote:
  On Wed, Sep 3, 2014 at 2:54 PM, Stefan Bodewig bode...@apache.org
 wrote:
 
  On 2014-09-03, sebb wrote:
 
   Maybe it's possible to configure the commit messages so that diffs are
   shown; if not, then perhaps there needs to be a convention for how to
   comment on commits.
 
  Might be something that can be configured per project, we do get diffs
  for commits in Ant-land: for example
 
 
 http://mail-archives.apache.org/mod_mbox/ant-notifications/201408.mbox/%3C20bedaba96cd4b7582e31104e4d27d4a%40git.apache.org%3E
 
 
  Diffs in mail notifications come for free in the ASF Git setup.

 OK, good.

 I was going by the infra puppet diffs on  infrastructure-cvs which
 only have a compare URL.

 But it seems these are github commits.


I also noticed those commits.
I'll ask Tony (tonypc) how this works for them.
I know Joe (joes) was strongly against using non-ASF services for Apache
needs. Apparently this changed!
I see Apache Spark also makes a heavy use of GitHub but I don't know the
details again.
Joe (and the whole Infra team) was against using Atlassian Stash (
https://www.atlassian.com/software/stash) on ASF hardware. ASF already uses
several other Atlassian product like JIRA, Confluence, HipChat, FishEye.
Stash is the application behind bitbucket.org. I find it even better than
GitHub user experience.



  Commenting on diffs in the email is not the important thing. Having an
  email means that another committer (i.e. someone with more knowledge) did
  something.
  The new thing is being able to comment on the patch (the Pull Request)
  provided by a contributor *before* it gets in the repo. Usually the
  contributors don't have the whole picture.

 Yes, this would be useful.

 However, it is fairly common for Tomcat committers to comment on each
 other's commits, either as part of CTR or sometimes to provide
 feedback. etc.
 A quick scan of some recent commits shows 5-10% with comments.

 
 
 
  Stefan
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
  For additional commands, e-mail: dev-h...@tomcat.apache.org
 
 

 -
 To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: dev-h...@tomcat.apache.org




Re: git (yet again)

2014-09-03 Thread Mark Thomas
On 02/09/2014 20:28, Konstantin Kolinko wrote:
 In July I successfully configured Git to operate on the same set of
 files as Subversion, on Windows.

Neat.

I use completely separate git and svn checkouts and swap between them as
the mood suits me. As I get more familiar with git then I am using git
more. Generally the only time when I have issues is when I try and take
a short cut and do git development directly on trunk and then realise
the issue is more complex and I really should be using a branch.

 Impressions etc.
 
 1. Such workflow works. It is great for building up experience with the tool.
 
 It also allows us to discuss Mark's a) decide how we want to organise
 development in git  point, without actually moving to Git.
 
 I think I can document it on a Wiki page, if others are interested.

My impression is that it is more complex to set up than [1] and might
make folks think git is more difficult to work with than it really is.

 2. An annoying fact is that the Git repository at git.apache.org lags
 for up to one hour behind the Subversion one.
 
 The symptoms are as if the git svn pull is performed via some cron
 job, instead of a postcommit hook or svn-pub-sub.  I wonder whether
 the Infra team can make it work better.

The sync from svn to the git.a.o is based on svn-pub-sub and is meant to
be close to real time. The replication it github is less frequent.
Obviously this would cease to be an issue if we moved to git (note there
is no git - svn process to keep the old svn repo up to date).

 3. I would like to commit my .git/info/attributes file as
 .gitattributes into Subversion.

Can you put that file somewhere where others can take a look at it first?

 4. My impression is that Git works slower.

My impression has been the opposite. git-svn is a little slower than
just svn but that is expected since there is an extra layer. When I use
git at work (with github) things seem very quick.

 My points from the previous thread on this topic:
 http://markmail.org/message/m7ig5a7wunyewdy6
 
 Areas where we depend on Subversion and need to implement a fix before the 
 move:
 1). There is svn externals reference from Tomcat Native to Tomcat Trunk.
 
 (Does it mean that we have to migrate TC Native to Git at the same time?
 Can we remove this svn externals reference?)

We'd move Tomcat Native at the same time. There are equivalent features
we can use to continue to use something svn external like. [2]

 2). svn revision numbers are used by the config difference form in the
 Migration guide.
 http://tomcat.apache.org/migration-8.html#Upgrading_8.0.x
 
 (Is it possible to replace it with links to similar Git tools, e.g. to
 compare pages on GitHub? Does HTML GUI at git.apache.org have
 similar history and compare pages?)

I'm sure we could come up with something.

 3). The plan to create a Maven build (BZ 56397) relies on svn externals.
 (I think it is time to abandon the idea.)

I'm happy to leave this open for now. We could do this using one of the
ideas in [2].

 6. Maybe move away modules/bayeux  and modules/tomcat-lite  ?

My expectation was that these would be left behind in svn.


[1] http://wiki.apache.org/general/GitAtApache
[2] http://stackoverflow.com/questions/571232/svnexternals-equivalent-in-git

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



Re: git (yet again)

2014-09-03 Thread Rainer Jung


Am 02.09.2014 um 18:41 schrieb Mark Thomas:

I've been looking at this again (anything to get a break from writing
parsers for cookies) and chatting with some of the infra folks that look
after the ASF's git repos.

There are a couple of things we need to do:
a) decide how we want to organise development in git
b) decide if we want to move to git

Now the decision we make for a) might influence some folks to make a
different decision for b). On the other hand, there is no point debating
a) if we are never going to move.

So, how do folks want to approach this?



A: Vote to move to git and then figure out how best to use it? or
B: Agree our git workflows and then have a vote on moving to git with
those workflows?

I'm leaning towards A myself.


It looks like the discussion in january and the answers on this thread 
show a majority for a move to git (not necessarily a consensus). I'd 
prefer if we knew more about the details before finally voting on it, so 
B, and I expect the time and work needed for that will not be wasted.


I agree with others about items for a). Things that come into my mind:

- one repos or multiple: Actually I dont't care about that question per 
se, but more about the implications that will have (which I'm not sure 
about). For instance, does it matter in git, that we would only have one 
master (trunk), and the heads of the versions only as branches?


- backport workflow
  I find trunk first, then version branches slightly better, but it 
might depend on details unknown to me. Concerning cherry-pick this 
seems to break the link between the original (e.g. master) commit and 
the commit on the branch. Not a good thing IMHO.


- use of temporary feature or backport branches: delete after merge?

- handling pull requests (tracking patch authors)

- move tomcat-connectors as well, same repos? No preference here.

- move old branches to simplify code archeology? I'd prefer so.

- sources for the web site remain in svn?

- is there (in principle) a way back from git to svn, or is this a one 
way street? No details needed, but if the project finds out the move was 
a bad thing, are we confident, that we can get back?


- Konstantin provided some reasons against git during the last three 
discussions. Some of the might be mitigated by now (e.g. svn externals 
vs. git submodules? Version diffs), some of them might not (Buildbot and 
Jenkins integration, missing EU mirror).


I guess experienced git users (like Martin Grigorov) could answer most 
questions easily, but I don't have the experience with git allowing me 
to understand implications of decisions.


Regards,

Rainer

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



Re: git (yet again)

2014-09-03 Thread sebb
On 3 September 2014 10:41, Rainer Jung rainer.j...@kippdata.de wrote:

 Am 02.09.2014 um 18:41 schrieb Mark Thomas:

 I've been looking at this again (anything to get a break from writing
 parsers for cookies) and chatting with some of the infra folks that look
 after the ASF's git repos.

 There are a couple of things we need to do:
 a) decide how we want to organise development in git
 b) decide if we want to move to git

 Now the decision we make for a) might influence some folks to make a
 different decision for b). On the other hand, there is no point debating
 a) if we are never going to move.

 So, how do folks want to approach this?


 A: Vote to move to git and then figure out how best to use it? or
 B: Agree our git workflows and then have a vote on moving to git with
 those workflows?


There's one aspect of Git that does not seem to have been covered here:
the commit messages don't seem to include what was actually changed.

So in order to review a commit, it is necessary to click the link.
In turn, this makes it harder to comment on a change.
This is something that happens quite frequently with the SVN commit messages.

Maybe it's possible to configure the commit messages so that diffs are
shown; if not, then perhaps there needs to be a convention for how to
comment on commits.

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



Re: git (yet again)

2014-09-03 Thread Emmanuel Bourg
Le 03/09/2014 12:17, sebb a écrit :

 Maybe it's possible to configure the commit messages so that diffs are
 shown; if not, then perhaps there needs to be a convention for how to
 comment on commits.

I confirm this is possible, here is for example a commit message for a
change on the tomcat8 package in Debian:

http://lists.alioth.debian.org/pipermail/pkg-java-commits/2014-July/032758.html

The commits are also threaded and grouped by push, see:

http://lists.alioth.debian.org/pipermail/pkg-java-commits/2014-July/thread.html

Emmanuel Bourg


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



Re: git (yet again)

2014-09-03 Thread Martin Grigorov
Hi all,

On Sep 3, 2014 12:42 PM, Rainer Jung rainer.j...@kippdata.de wrote:


 Am 02.09.2014 um 18:41 schrieb Mark Thomas:

 I've been looking at this again (anything to get a break from writing
 parsers for cookies) and chatting with some of the infra folks that look
 after the ASF's git repos.

 There are a couple of things we need to do:
 a) decide how we want to organise development in git
 b) decide if we want to move to git

 Now the decision we make for a) might influence some folks to make a
 different decision for b). On the other hand, there is no point debating
 a) if we are never going to move.

 So, how do folks want to approach this?


 A: Vote to move to git and then figure out how best to use it? or
 B: Agree our git workflows and then have a vote on moving to git with
 those workflows?

 I'm leaning towards A myself.


 It looks like the discussion in january and the answers on this thread
show a majority for a move to git (not necessarily a consensus). I'd prefer
if we knew more about the details before finally voting on it, so B, and
I expect the time and work needed for that will not be wasted.

 I agree with others about items for a). Things that come into my mind:

 - one repos or multiple: Actually I dont't care about that question per
se, but more about the implications that will have (which I'm not sure
about). For instance, does it matter in git, that we would only have one
master (trunk), and the heads of the versions only as branches?

I am not sure how merging/cherry-pucking would work in separate repos.
As I said before I use git-new-workdir to have different local working
folders for branches of the same repo. This way I can have several branches
opened simultaneously in the IDE. Konstantin noted that this doesn't work
on Windows at the moment.


 - backport workflow
   I find trunk first, then version branches slightly better, but it
might depend on details unknown to me. Concerning cherry-pick this seems
to break the link between the original (e.g. master) commit and the commit
on the branch. Not a good thing IMHO.

Each cherry picked commit has the sha id of the original in its message
automatically. Additionally with git cherry you can check the branches a
commit has been picked.


 - use of temporary feature or backport branches: delete after merge?

Branching in Git is cheap. You can keep them if you want. Feature branches
are usually deleted after merge.


 - handling pull requests (tracking patch authors)

Apache committers don't have write access to GitHub mirrors. I have a Shell
script to merge Pull Requests and preserve the authorship.
The PR is automatically closed once the code is sync-ed as Mark already
said.

Commenting on code in a feature branch at GitHub UI doesn't notify the
author nor the team. Not ideal!


 - move tomcat-connectors as well, same repos? No preference here.

 - move old branches to simplify code archeology? I'd prefer so.

Most svn2git scripts support this.


 - sources for the web site remain in svn?

This is the case for Apache Wicket. I'd like to change it to Git too.


 - is there (in principle) a way back from git to svn, or is this a one
way street? No details needed, but if the project finds out the move was a
bad thing, are we confident, that we can get back?

 - Konstantin provided some reasons against git during the last three
discussions. Some of the might be mitigated by now (e.g. svn externals vs.
git submodules? Version diffs), some of them might not (Buildbot and
Jenkins integration, missing EU mirror).

We use BuildBot without problems.

For me US Git is much faster than EU SVN. I live in Bulgaria.


 I guess experienced git users (like Martin Grigorov) could answer most
questions easily, but I don't have the experience with git allowing me to
understand implications of decisions.

 Regards,

 Rainer


 -
 To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: dev-h...@tomcat.apache.org



Re: git (yet again)

2014-09-03 Thread Stefan Bodewig
On 2014-09-03, sebb wrote:

 Maybe it's possible to configure the commit messages so that diffs are
 shown; if not, then perhaps there needs to be a convention for how to
 comment on commits.

Might be something that can be configured per project, we do get diffs
for commits in Ant-land: for example
http://mail-archives.apache.org/mod_mbox/ant-notifications/201408.mbox/%3C20bedaba96cd4b7582e31104e4d27d4a%40git.apache.org%3E

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



Re: git (yet again)

2014-09-03 Thread Martin Grigorov
On Wed, Sep 3, 2014 at 2:54 PM, Stefan Bodewig bode...@apache.org wrote:

 On 2014-09-03, sebb wrote:

  Maybe it's possible to configure the commit messages so that diffs are
  shown; if not, then perhaps there needs to be a convention for how to
  comment on commits.

 Might be something that can be configured per project, we do get diffs
 for commits in Ant-land: for example

 http://mail-archives.apache.org/mod_mbox/ant-notifications/201408.mbox/%3C20bedaba96cd4b7582e31104e4d27d4a%40git.apache.org%3E


Diffs in mail notifications come for free in the ASF Git setup.

Commenting on diffs in the email is not the important thing. Having an
email means that another committer (i.e. someone with more knowledge) did
something.
The new thing is being able to comment on the patch (the Pull Request)
provided by a contributor *before* it gets in the repo. Usually the
contributors don't have the whole picture.




 Stefan

 -
 To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: dev-h...@tomcat.apache.org




Re: git (yet again)

2014-09-03 Thread sebb
On 3 September 2014 16:10, Martin Grigorov mgrigo...@apache.org wrote:
 On Wed, Sep 3, 2014 at 2:54 PM, Stefan Bodewig bode...@apache.org wrote:

 On 2014-09-03, sebb wrote:

  Maybe it's possible to configure the commit messages so that diffs are
  shown; if not, then perhaps there needs to be a convention for how to
  comment on commits.

 Might be something that can be configured per project, we do get diffs
 for commits in Ant-land: for example

 http://mail-archives.apache.org/mod_mbox/ant-notifications/201408.mbox/%3C20bedaba96cd4b7582e31104e4d27d4a%40git.apache.org%3E


 Diffs in mail notifications come for free in the ASF Git setup.

OK, good.

I was going by the infra puppet diffs on  infrastructure-cvs which
only have a compare URL.

But it seems these are github commits.

 Commenting on diffs in the email is not the important thing. Having an
 email means that another committer (i.e. someone with more knowledge) did
 something.
 The new thing is being able to comment on the patch (the Pull Request)
 provided by a contributor *before* it gets in the repo. Usually the
 contributors don't have the whole picture.

Yes, this would be useful.

However, it is fairly common for Tomcat committers to comment on each
other's commits, either as part of CTR or sometimes to provide
feedback. etc.
A quick scan of some recent commits shows 5-10% with comments.




 Stefan

 -
 To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: dev-h...@tomcat.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



Re: git (yet again)

2014-09-02 Thread Rémy Maucherat
2014-09-02 18:41 GMT+02:00 Mark Thomas ma...@apache.org:

 I'm leaning towards A myself.


Oh wow, does this mean I can resurrect my thread on Maven too ? (ideally,
we should also move to it first, then think about how to use it later,
otherwise people will never vote in favor)

:)

Rémy


Re: git (yet again)

2014-09-02 Thread Sylvain Laurent
Regarding question b), I vote yes, whatever the organization of the development

Regarding a), for my part I rather see something between A and B. I think of 
the following questions that should be answered first :
- will there be 1 repo per major version like the current SVN setup ? or only 
branches in a unique repo ? 
- how to backport modifications from one major version to another ? is 
cherry-picking ok ?
- where will the main repo be (the one committers will push to)? ASF or github 
? where should we open and treat pull requests, ASF or github ? (currently 
having the SVN repo at ASF and pull requests at github is not convenient)

Sylvain

On 2 sept. 2014, at 18:41, Mark Thomas ma...@apache.org wrote:

 I've been looking at this again (anything to get a break from writing
 parsers for cookies) and chatting with some of the infra folks that look
 after the ASF's git repos.
 
 There are a couple of things we need to do:
 a) decide how we want to organise development in git
 b) decide if we want to move to git
 
 Now the decision we make for a) might influence some folks to make a
 different decision for b). On the other hand, there is no point debating
 a) if we are never going to move.
 
 So, how do folks want to approach this?
 A: Vote to move to git and then figure out how best to use it? or
 B: Agree our git workflows and then have a vote on moving to git with
 those workflows?
 
 I'm leaning towards A myself.
 
 Mark
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: dev-h...@tomcat.apache.org
 


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



Re: git (yet again)

2014-09-02 Thread Henri Gomez
Maven Strike back ?

That would be a very good new and our friend Olivier Lamy will be more than
happy :)


2014-09-02 18:52 GMT+02:00 Rémy Maucherat r...@apache.org:

 2014-09-02 18:41 GMT+02:00 Mark Thomas ma...@apache.org:

  I'm leaning towards A myself.
 

 Oh wow, does this mean I can resurrect my thread on Maven too ? (ideally,
 we should also move to it first, then think about how to use it later,
 otherwise people will never vote in favor)

 :)

 Rémy



Re: git (yet again)

2014-09-02 Thread Henri Gomez
About git workflow.

Github popularized fork/pull-request mode and it helped enrolled tons of
new developpers in many Git projects, in Github but not only.
Would it be something possible with current Git infra in ASF ?

Side note, did infra folks plans to use a new git hosting ?
Using Stash, Gitlab, Gitblit ? Or GitBucket (this implementation came from
an ASFer) ?



2014-09-02 18:41 GMT+02:00 Mark Thomas ma...@apache.org:

 I've been looking at this again (anything to get a break from writing
 parsers for cookies) and chatting with some of the infra folks that look
 after the ASF's git repos.

 There are a couple of things we need to do:
 a) decide how we want to organise development in git
 b) decide if we want to move to git

 Now the decision we make for a) might influence some folks to make a
 different decision for b). On the other hand, there is no point debating
 a) if we are never going to move.

 So, how do folks want to approach this?
 A: Vote to move to git and then figure out how best to use it? or
 B: Agree our git workflows and then have a vote on moving to git with
 those workflows?

 I'm leaning towards A myself.

 Mark

 -
 To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: dev-h...@tomcat.apache.org




Re: git (yet again)

2014-09-02 Thread Mark Thomas
On 02/09/2014 19:24, Sylvain Laurent wrote:
 Regarding question b), I vote yes, whatever the organization of the 
 development
 
 Regarding a), for my part I rather see something between A and B. I think of 
 the following questions that should be answered first :
 - will there be 1 repo per major version like the current SVN setup ? or only 
 branches in a unique repo ?

It is up to us.

aside
The current svn setup is a single repo.
/aside

My preference is for a single git repo with branches for 7.0.x and 6.0.x

 - how to backport modifications from one major version to another ? is 
 cherry-picking ok ?

Again, it is up to us. I see two basic choices.

a) Make change in master and cherry pick to backport
b) Make changes in earliest branch that needs the change and merge
forward until we reach trunk/master

a) is closer to how we work now. b) is 'nicer'. a) is more flexible.

I have a slight preference for a) but I'm happy with either.

 - where will the main repo be (the one committers will push to)? ASF or 
 github ? where should we open and treat pull requests, ASF or github ? 
 (currently having the SVN repo at ASF and pull requests at github is not 
 convenient)

The canonical location for the source for an ASF project is ALWAYS the
ASF. The repo will be mirrored at github. The github integration makes
working with github pull requests very easy - we are doing this already.

Mark


 
 Sylvain
 
 On 2 sept. 2014, at 18:41, Mark Thomas ma...@apache.org wrote:
 
 I've been looking at this again (anything to get a break from writing
 parsers for cookies) and chatting with some of the infra folks that look
 after the ASF's git repos.

 There are a couple of things we need to do:
 a) decide how we want to organise development in git
 b) decide if we want to move to git

 Now the decision we make for a) might influence some folks to make a
 different decision for b). On the other hand, there is no point debating
 a) if we are never going to move.

 So, how do folks want to approach this?
 A: Vote to move to git and then figure out how best to use it? or
 B: Agree our git workflows and then have a vote on moving to git with
 those workflows?

 I'm leaning towards A myself.

 Mark

 -
 To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: dev-h...@tomcat.apache.org

 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: dev-h...@tomcat.apache.org
 


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



Re: git (yet again)

2014-09-02 Thread Mark Thomas
On 02/09/2014 19:31, Henri Gomez wrote:
 About git workflow.
 
 Github popularized fork/pull-request mode and it helped enrolled tons of
 new developpers in many Git projects, in Github but not only.
 Would it be something possible with current Git infra in ASF ?

The git repo would be mirrored at github. Folks can open pull requests
at gitbuh now and we can close them when we commit the changes. That
won't change if we switch to git.

 Side note, did infra folks plans to use a new git hosting ?
 Using Stash, Gitlab, Gitblit ? Or GitBucket (this implementation came from
 an ASFer) ?

No plans to change current arrangement.

Mark

 
 
 
 2014-09-02 18:41 GMT+02:00 Mark Thomas ma...@apache.org:
 
 I've been looking at this again (anything to get a break from writing
 parsers for cookies) and chatting with some of the infra folks that look
 after the ASF's git repos.

 There are a couple of things we need to do:
 a) decide how we want to organise development in git
 b) decide if we want to move to git

 Now the decision we make for a) might influence some folks to make a
 different decision for b). On the other hand, there is no point debating
 a) if we are never going to move.

 So, how do folks want to approach this?
 A: Vote to move to git and then figure out how best to use it? or
 B: Agree our git workflows and then have a vote on moving to git with
 those workflows?

 I'm leaning towards A myself.

 Mark

 -
 To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: dev-h...@tomcat.apache.org


 


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



Re: git (yet again)

2014-09-02 Thread Henri Gomez
The git repo would be mirrored at github. Folks can open pull requests
at gitbuh now and we can close them when we commit the changes. That
won't change if we switch to git.

There is mecansims to merge pull-requests for GitHub in Git ASF ?
How is documented somewhere ?


  Side note, did infra folks plans to use a new git hosting ?
  Using Stash, Gitlab, Gitblit ? Or GitBucket (this implementation came
 from
  an ASFer) ?


 No plans to change current arrangement.

Ok, no problems


Re: git (yet again)

2014-09-02 Thread Filip Hanik
On Tue, Sep 2, 2014 at 10:52 AM, Rémy Maucherat r...@apache.org wrote:

 2014-09-02 18:41 GMT+02:00 Mark Thomas ma...@apache.org:

  I'm leaning towards A myself.


​
The move to git clears a huge hurdle, and that is managing contributions.
The patch system is very difficult, and impossible to maintain. A pull
request stays alive
​ and can be maintained through code changes​
. I believe we can get more contributions by moving to Git.
​


 

 Oh wow, does this mean I can resurrect my thread on Maven too ? (ideally,
 we should also move to it first, then think about how to use it later,
 otherwise people will never vote in favor)


​Let's skip Maven and move straight to Gradle, it has the benefit of not
needing a build system installed on the developers machine, as it gets
downloaded by the wrapper checked into the repo. This is yet one less
version that is required by the contributor.
It's built on top of Ant, and should give us all the flexibility we need.​



 :)

 Rémy



Re: git (yet again)

2014-09-02 Thread Konstantin Kolinko
2014-09-02 20:41 GMT+04:00 Mark Thomas ma...@apache.org:
 I've been looking at this again (anything to get a break from writing
 parsers for cookies) and chatting with some of the infra folks that look
 after the ASF's git repos.

 There are a couple of things we need to do:
 a) decide how we want to organise development in git
 b) decide if we want to move to git

 Now the decision we make for a) might influence some folks to make a
 different decision for b). On the other hand, there is no point debating
 a) if we are never going to move.

 So, how do folks want to approach this?
 A: Vote to move to git and then figure out how best to use it? or
 B: Agree our git workflows and then have a vote on moving to git with
 those workflows?

 I'm leaning towards A myself.

We shall discuss the workflows and our expectations first.

In July I successfully configured Git to operate on the same set of
files as Subversion, on Windows.

That is: I have a sparse subversion workng copy  that spans the whole
of site/trunk, tc6.0.x/trunk, tc7.0.x/trunk and trunk,  and I have
.git directories in each of the branches.

It works. If both Git and Subversion data are up-to-date, the status
command in both shows no changes (except an occasional uncommitted
bin/tcnative-1.dll that is used to run JUnit tests with APR).

As such, I use Git to prepare sets of changes and use Subversion
client to commit them when they are ready.

Technical bits:

1. I am using TortoiseGit (64-bit) and msysGit (32-bit).

2. I cloned the repositories from git://git.apache.org/

3. I have not initialized git-svn on this repository. I do not use it.

4. I have eol-conversion options turned off (the default) and I have
.git/info/attributes  files in my local repositories that configure
Git to apply text attribute to the same set of files that are
treated as textual (patternset id=text.files ) in build.xml,  the
same ones that have svn:eol-style=native in Subversion.

5. To pull fresh changes one has to update both subversion wc and
local git repository. Both svn, git and git, svn update sequences
do work successfully.

I prefer svn, git, because it works a bit better and because git
repository lags behind subversion one.

6. To update the local trunk branch in Git according to master
repository the following works:
a) Git Sync command in TortoiseGit, using Fetch and Rebase operation there
b) In command line (Git Shell) it maps to the following sequence of commands:
git stash -u
git pull --rebase --verbose
git stash pop

Impressions etc.

1. Such workflow works. It is great for building up experience with the tool.

It also allows us to discuss Mark's a) decide how we want to organise
development in git  point, without actually moving to Git.

I think I can document it on a Wiki page, if others are interested.

I used this workflow to prepare some patches when I had no network
access (traveling on a train across some sticks) and to commit them
when I had access.


2. An annoying fact is that the Git repository at git.apache.org lags
for up to one hour behind the Subversion one.

The symptoms are as if the git svn pull is performed via some cron
job, instead of a postcommit hook or svn-pub-sub.  I wonder whether
the Infra team can make it work better.


3. I would like to commit my .git/info/attributes file as
.gitattributes into Subversion.

My concerns before committing it:
a) If any of you are using Git on Windows, such commit probably means
that you have to git checkout trunk a fresh set of files so that
they get CRLF line ends applied from this setting.

b) I do not know whether this interoperates with git-svn, if any of
you are using it. We may give it a try and rollback later.  In any
case, if there is anything wrong, a local .git/info/attributes file
can be used to overwrite the setting, as it has precedence over the
repository-provided .gitattributes one.

Documentation:
https://www.kernel.org/pub/software/scm/git/docs/gitattributes.html

At the same time. I think it would be good to commit an svn:auto-props
property that applies svn:eol-style=native for the same set of files
for Subversion clients.

By the way Apache Subversion project configured a svn:auto-props
property for their project today,
http://svn.apache.org/r1621946


4. My impression is that Git works slower.

Maybe it is no so optimized, has less optimal database structure, or
does more work.

5. I think that now I will be able to continue working on Tomcat if we
migrate to Git,
but I am not yet convinced that it is worth moving,
and several issues listed below have to be fixed before the move.

My points from the previous thread on this topic:
http://markmail.org/message/m7ig5a7wunyewdy6

Areas where we depend on Subversion and need to implement a fix before the move:
1). There is svn externals reference from Tomcat Native to Tomcat Trunk.

(Does it mean that we have to migrate TC Native to Git at the same time?
Can we remove this svn externals 

Re: git (yet again)

2014-09-02 Thread sebb
On 2 September 2014 20:25, Filip Hanik fi...@hanik.com wrote:
 On Tue, Sep 2, 2014 at 10:52 AM, Rémy Maucherat r...@apache.org wrote:

 2014-09-02 18:41 GMT+02:00 Mark Thomas ma...@apache.org:

  I'm leaning towards A myself.



 The move to git clears a huge hurdle, and that is managing contributions.
 The patch system is very difficult, and impossible to maintain. A pull
 request stays alive
 and can be maintained through code changes
 . I believe we can get more contributions by moving to Git.



 

 Oh wow, does this mean I can resurrect my thread on Maven too ? (ideally,
 we should also move to it first, then think about how to use it later,
 otherwise people will never vote in favor)


 Let's skip Maven and move straight to Gradle, it has the benefit of not
 needing a build system installed on the developers machine, as it gets
 downloaded by the wrapper checked into the repo. This is yet one less

AIUI the wrapper is not source, it is binary.
Generally only source code is allowed in repos, so will this cause an issue?

 version that is required by the contributor.
 It's built on top of Ant, and should give us all the flexibility we need.



 :)

 Rémy


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



Re: git (yet again)

2014-09-02 Thread Henri Gomez
 Let's skip Maven and move straight to Gradle, it has the benefit of not
 needing a build system installed on the developers machine, as it gets
 downloaded by the wrapper checked into the repo. This is yet one less
 version that is required by the contributor.
 It's built on top of Ant, and should give us all the flexibility we need.


Maven is used by so many ASF projects and especially projects using Tomcat
like TomEE, it would be nice to share contents and expertises.
Also, Maven is way more used in companies than Gradle or Ant/Ivy.
It should help also for companies (or companies developpers) contribution.


Re: git (yet again)

2014-09-02 Thread Violeta Georgieva
Hi,


2014-09-02 22:15 GMT+03:00 Mark Thomas ma...@apache.org:

 ...
 It is up to us.

 aside
 The current svn setup is a single repo.
 /aside

 My preference is for a single git repo with branches for 7.0.x and 6.0.x

+1 one repo with many branches
master is the latest development in our case 8.0.x at the moment


  - how to backport modifications from one major version to another ? is
cherry-picking ok ?

 Again, it is up to us. I see two basic choices.

 a) Make change in master and cherry pick to backport

+1 cherry pick from master to other branches

 b) Make changes in earliest branch that needs the change and merge
 forward until we reach trunk/master

 a) is closer to how we work now. b) is 'nicer'. a) is more flexible.

 I have a slight preference for a) but I'm happy with either.


2014-09-02 22:28 GMT+03:00 Konstantin Kolinko knst.koli...@gmail.com:

 ...
 2). svn revision numbers are used by the config difference form in the
 Migration guide.
 http://tomcat.apache.org/migration-8.html#Upgrading_8.0.x

 (Is it possible to replace it with links to similar Git tools, e.g. to
 compare pages on GitHub? Does HTML GUI at git.apache.org have
 similar history and compare pages?)


https://github.com/apache/tomcat/compare


Regards,
Violeta


Re: git (yet again)

2014-09-02 Thread Violeta Georgieva
2014-09-02 23:22 GMT+03:00 Violeta Georgieva miles...@gmail.com:

 Hi,


 2014-09-02 22:15 GMT+03:00 Mark Thomas ma...@apache.org:
 
  ...

  It is up to us.
 
  aside
  The current svn setup is a single repo.
  /aside
 
  My preference is for a single git repo with branches for 7.0.x and 6.0.x

 +1 one repo with many branches
 master is the latest development in our case 8.0.x at the moment

 
   - how to backport modifications from one major version to another ?
is cherry-picking ok ?
 
  Again, it is up to us. I see two basic choices.
 
  a) Make change in master and cherry pick to backport

 +1 cherry pick from master to other branches

  b) Make changes in earliest branch that needs the change and merge
  forward until we reach trunk/master
 
  a) is closer to how we work now. b) is 'nicer'. a) is more flexible.
 
  I have a slight preference for a) but I'm happy with either.
 

 2014-09-02 22:28 GMT+03:00 Konstantin Kolinko knst.koli...@gmail.com:
 
  ...
  2). svn revision numbers are used by the config difference form in the
  Migration guide.
  http://tomcat.apache.org/migration-8.html#Upgrading_8.0.x
 
  (Is it possible to replace it with links to similar Git tools, e.g. to
  compare pages on GitHub? Does HTML GUI at git.apache.org have
  similar history and compare pages?)
 

 https://github.com/apache/tomcat/compare


One more thing - in github you can make inline comments for a given
commit/pull request.
This is very convenient for a review purposes.



 Regards,
 Violeta


Re: git (yet again)

2014-09-02 Thread Rémy Maucherat
2014-09-02 22:49 GMT+02:00 Violeta Georgieva miles...@gmail.com:

 One more thing - in github you can make inline comments for a given
 commit/pull request.
 This is very convenient for a review purposes.


Well, I guess since it is mirrored in github, you can comment there.

About the patching process, I would vote a) Make change in master and
cherry pick to backport.

For Maven, it was a joke, sorry for hijacking the thread. It should be
revisited later (or never). One last note: IMO Gradle sounds better, but
the point is to help integration so Maven is likely more useful.

Rémy