You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Mark Thomas <ma...@apache.org> on 2014/01/21 10:58:36 UTC
Git
I've been using Git more and more for Tomcat development and was
wondering what folks thought about moving Tomcat to git. This isn't a
formal proposal or a vote, I'm just trying to gather some views.
On the plus side:
- it is much easier to have multiple issues in progress at the
same time and switch between them
- being able to work off-line but still commit is a huge benefit
when working on a complex issue and you don't have internet
access
- merging between branches (assuming all supported branches were in a
single repo) is simpler
Neutral
- we would need to agree some simple guidelines for how we used git
- tooling seems equivalent to that available for svn (at for what I
use anyway)
On the down side:
- there is much more potential to mess things up
- cleaning up is potentially more complex
- the disruption of the move - particularly if we want to move to a
single git repo - could be significant
Thoughts?
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Git
Posted by Martin Grigorov <mg...@apache.org>.
Hi Rainer,
On Tue, Jan 21, 2014 at 1:01 PM, Rainer Jung <ra...@kippdata.de>wrote:
> On 21.01.2014 10:58, Mark Thomas wrote:
> > I've been using Git more and more for Tomcat development and was
> > wondering what folks thought about moving Tomcat to git. This isn't a
> > formal proposal or a vote, I'm just trying to gather some views.
> >
> > On the plus side:
> > - it is much easier to have multiple issues in progress at the
> > same time and switch between them
> > - being able to work off-line but still commit is a huge benefit
> > when working on a complex issue and you don't have internet
> > access
> > - merging between branches (assuming all supported branches were in a
> > single repo) is simpler
> >
> > Neutral
> > - we would need to agree some simple guidelines for how we used git
> > - tooling seems equivalent to that available for svn (at for what I
> > use anyway)
> >
> > On the down side:
> > - there is much more potential to mess things up
> > - cleaning up is potentially more complex
> > - the disruption of the move - particularly if we want to move to a
> > single git repo - could be significant
> >
> >
> > Thoughts?
>
> I am slightly positive for a move but there's one thing I was negatively
> surprised a couple of times: commit emails. Our current commit emails
> are very easy to read and contain all the needed information. I guess
> some of that will be adjustable for the git commit mails, but the ones I
> looked at today (using wicket as an example), had something like the
> first line of the commit log as the mail subject. That could be better
> or worse than what we have in svn currently, depending on the log message.
>
Yes, this is adjustable.
Just it is in the hands of Apache Infra.
I have asked once for read-only access to the Git hooks (
http://git-scm.com/book/en/Customizing-Git-Git-Hooks) but they rejected.
I guess it will be easier for you or Mark as Infra members.
>
> I remember having seen many "merge" type commit messages somewhere,
> where the subject basically carries no information on what was changed,
> because it always says "Merge". Sometimes such mails do not contain a
> diff in the body but only the information, which ids have been merged
> between which branches. These are the ones I find really unhelpful. I
> haven't dug deeper into it though.
>
The merge commits appear when you use "git merge" or "git pull" in the
fix/feature branch.
If you stick to "git rebase" or "git pull --rebase" then there is no such
"noise" in the Git history.
I use "git pull --rebase" daily and had no merge problems.
>
> The PHP project has a weekly or so message automated about pull requests
> waiting to be handled. Something like that might be needed because if we
> move to git the community will expect us to watch for contributions
> coming via GitHub.
>
Contributions via GitHub doesn't work well at the moment with Apache
projects. There are few discussions about this in members@.
I use https://github.com/github/hub to make it easier to merge remote
branches. I prefer command line but many devs don't.
>
> My 2ct.
>
> Rainer
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Re: Git
Posted by Rainer Jung <ra...@kippdata.de>.
On 21.01.2014 10:58, Mark Thomas wrote:
> I've been using Git more and more for Tomcat development and was
> wondering what folks thought about moving Tomcat to git. This isn't a
> formal proposal or a vote, I'm just trying to gather some views.
>
> On the plus side:
> - it is much easier to have multiple issues in progress at the
> same time and switch between them
> - being able to work off-line but still commit is a huge benefit
> when working on a complex issue and you don't have internet
> access
> - merging between branches (assuming all supported branches were in a
> single repo) is simpler
>
> Neutral
> - we would need to agree some simple guidelines for how we used git
> - tooling seems equivalent to that available for svn (at for what I
> use anyway)
>
> On the down side:
> - there is much more potential to mess things up
> - cleaning up is potentially more complex
> - the disruption of the move - particularly if we want to move to a
> single git repo - could be significant
>
>
> Thoughts?
I am slightly positive for a move but there's one thing I was negatively
surprised a couple of times: commit emails. Our current commit emails
are very easy to read and contain all the needed information. I guess
some of that will be adjustable for the git commit mails, but the ones I
looked at today (using wicket as an example), had something like the
first line of the commit log as the mail subject. That could be better
or worse than what we have in svn currently, depending on the log message.
I remember having seen many "merge" type commit messages somewhere,
where the subject basically carries no information on what was changed,
because it always says "Merge". Sometimes such mails do not contain a
diff in the body but only the information, which ids have been merged
between which branches. These are the ones I find really unhelpful. I
haven't dug deeper into it though.
The PHP project has a weekly or so message automated about pull requests
waiting to be handled. Something like that might be needed because if we
move to git the community will expect us to watch for contributions
coming via GitHub.
My 2ct.
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Git
Posted by Henri Gomez <he...@gmail.com>.
> Also +1 to separating the git vs svn discussion from the build system
> discussion (Maven, Ant, whatever.) (Side note: been using gradle
> recently, fun.)
+1 for split
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Git
Posted by sebb <se...@gmail.com>.
AIUI SVN will still be mandated by Infra for
- release publishing
- site publishing
Release publishing should not cause an issue.
However site publishing may perhaps be tricker to do from a GIT repo;
might need to consider leaving site docs in SVN.
On 24 February 2014 17:43, Jeremy Boynes <jb...@apache.org> wrote:
> Setting aside Maven and Gradle, did we reach any consensus on Git?
>
> On Jan 26, 2014, at 5:34 PM, Costin Manolache <co...@gmail.com> wrote:
>
>> Gradle is becoming the standard build tool for android.
>> I didn't like it at first - I don't really see the point of groovy - but
>> it's still better than 'programming'
>> in ant, and you don't have to touch any XML. You can use any ant task from
>> gradle - best to think of it as a non-xml ant file, with reasonable
>> defaults and less typing for the most common operations.
>>
>> Git is best.
>>
>> Costin
>>
>>
>> On Tue, Jan 21, 2014 at 7:49 AM, Rémy Maucherat <re...@apache.org> wrote:
>>
>>> 2014/1/21 Yoav Shapira <yo...@apache.org>
>>>
>>>> Also +1 to separating the git vs svn discussion from the build system
>>>> discussion (Maven, Ant, whatever.) (Side note: been using gradle
>>>> recently, fun.)
>>>>
>>>
>>> +1
>>>
>>> Never used that Gradle yet though.
>>>
>>> Rémy
>>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Git
Posted by Jeremy Boynes <jb...@apache.org>.
Setting aside Maven and Gradle, did we reach any consensus on Git?
On Jan 26, 2014, at 5:34 PM, Costin Manolache <co...@gmail.com> wrote:
> Gradle is becoming the standard build tool for android.
> I didn't like it at first - I don't really see the point of groovy - but
> it's still better than 'programming'
> in ant, and you don't have to touch any XML. You can use any ant task from
> gradle - best to think of it as a non-xml ant file, with reasonable
> defaults and less typing for the most common operations.
>
> Git is best.
>
> Costin
>
>
> On Tue, Jan 21, 2014 at 7:49 AM, Rémy Maucherat <re...@apache.org> wrote:
>
>> 2014/1/21 Yoav Shapira <yo...@apache.org>
>>
>>> Also +1 to separating the git vs svn discussion from the build system
>>> discussion (Maven, Ant, whatever.) (Side note: been using gradle
>>> recently, fun.)
>>>
>>
>> +1
>>
>> Never used that Gradle yet though.
>>
>> Rémy
>>
Re: Git
Posted by Costin Manolache <co...@gmail.com>.
Gradle is becoming the standard build tool for android.
I didn't like it at first - I don't really see the point of groovy - but
it's still better than 'programming'
in ant, and you don't have to touch any XML. You can use any ant task from
gradle - best to think of it as a non-xml ant file, with reasonable
defaults and less typing for the most common operations.
Git is best.
Costin
On Tue, Jan 21, 2014 at 7:49 AM, Rémy Maucherat <re...@apache.org> wrote:
> 2014/1/21 Yoav Shapira <yo...@apache.org>
>
> > Also +1 to separating the git vs svn discussion from the build system
> > discussion (Maven, Ant, whatever.) (Side note: been using gradle
> > recently, fun.)
> >
>
> +1
>
> Never used that Gradle yet though.
>
> Rémy
>
Re: Git
Posted by Rémy Maucherat <re...@apache.org>.
2014/1/21 Yoav Shapira <yo...@apache.org>
> Also +1 to separating the git vs svn discussion from the build system
> discussion (Maven, Ant, whatever.) (Side note: been using gradle
> recently, fun.)
>
+1
Never used that Gradle yet though.
Rémy
Re: Git
Posted by Yoav Shapira <yo...@apache.org>.
Others have mostly captured the pros and cons, so mine is brief...
On Tue, Jan 21, 2014 at 4:58 AM, Mark Thomas <ma...@apache.org> wrote:
> I've been using Git more and more for Tomcat development and was
> wondering what folks thought about moving Tomcat to git. This isn't a
> formal proposal or a vote, I'm just trying to gather some views.
+1 to Git.
My main pro from it is speed. Everything feels speedier: commits,
diffs, pushes, pulls, etc.
I don't think the potential for messing up is bigger. At least, not
bigger than learning any new tools (for those of us who would have to
learn git). I switched to primarily-git SCM about 2 years ago and
haven't had any more mishaps than I would have with svn merging, I
don't think.
Also +1 to separating the git vs svn discussion from the build system
discussion (Maven, Ant, whatever.) (Side note: been using gradle
recently, fun.)
Yoav
>
> On the plus side:
> - it is much easier to have multiple issues in progress at the
> same time and switch between them
> - being able to work off-line but still commit is a huge benefit
> when working on a complex issue and you don't have internet
> access
> - merging between branches (assuming all supported branches were in a
> single repo) is simpler
>
> Neutral
> - we would need to agree some simple guidelines for how we used git
> - tooling seems equivalent to that available for svn (at for what I
> use anyway)
>
> On the down side:
> - there is much more potential to mess things up
> - cleaning up is potentially more complex
> - the disruption of the move - particularly if we want to move to a
> single git repo - could be significant
>
>
> Thoughts?
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Git
Posted by Henri Gomez <he...@gmail.com>.
Hi all
+1 for Git
About Maven, it will be a very good move also.
There is tons of projects inside ASF using Maven as their build tool.
There is also so many projects using Tomcat artefacts, hosted on
Central, that it will make their life easier if Maven was used has
main build tool for Tomcat.
One of Tomcat number one user, TomEE project, would certainly be more
than happy to see Tomcat Mavenized.
There is really tons of goods things in Maven, and when it's release
time, Maven Release Plugin, is a safe and fast approach.
One of our members, Olivier Lamy, worked on a Maven layout for Tomcat,
outside Tomcat trunk and it worked well.
And you should all know Olivier enough to know is mastering in Maven
area, so you'll never be alone or stuck.
So please, "ne jetez pas la bébé avec l'eau du bain", and take
sometime to reconsider positivly using Maven for Tomcat.
2014/1/21 Violeta Georgieva <mi...@gmail.com>:
> 2014/1/21 Mark Thomas <ma...@apache.org>
>>
>> I've been using Git more and more for Tomcat development and was
>> wondering what folks thought about moving Tomcat to git. This isn't a
>> formal proposal or a vote, I'm just trying to gather some views.
>>
>> On the plus side:
>> - it is much easier to have multiple issues in progress at the
>> same time and switch between them
>> - being able to work off-line but still commit is a huge benefit
>> when working on a complex issue and you don't have internet
>> access
>> - merging between branches (assuming all supported branches were in a
>> single repo) is simpler
>>
>> Neutral
>> - we would need to agree some simple guidelines for how we used git
>> - tooling seems equivalent to that available for svn (at for what I
>> use anyway)
>>
>> On the down side:
>> - there is much more potential to mess things up
>> - cleaning up is potentially more complex
>> - the disruption of the move - particularly if we want to move to a
>> single git repo - could be significant
>>
>>
>> Thoughts?
>
> +1 for Git
>
> About Maven I share Mark's opinion. I have more negative experience than
> positive.
>
> Regards
> Violeta
>
>> Mark
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Git
Posted by Violeta Georgieva <mi...@gmail.com>.
2014/1/21 Mark Thomas <ma...@apache.org>
>
> I've been using Git more and more for Tomcat development and was
> wondering what folks thought about moving Tomcat to git. This isn't a
> formal proposal or a vote, I'm just trying to gather some views.
>
> On the plus side:
> - it is much easier to have multiple issues in progress at the
> same time and switch between them
> - being able to work off-line but still commit is a huge benefit
> when working on a complex issue and you don't have internet
> access
> - merging between branches (assuming all supported branches were in a
> single repo) is simpler
>
> Neutral
> - we would need to agree some simple guidelines for how we used git
> - tooling seems equivalent to that available for svn (at for what I
> use anyway)
>
> On the down side:
> - there is much more potential to mess things up
> - cleaning up is potentially more complex
> - the disruption of the move - particularly if we want to move to a
> single git repo - could be significant
>
>
> Thoughts?
+1 for Git
About Maven I share Mark's opinion. I have more negative experience than
positive.
Regards
Violeta
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
Re: Git
Posted by Rémy Maucherat <re...@apache.org>.
2014/1/21 Mark Thomas <ma...@apache.org>
> > Since we're considering big changes, what about Maven too ? I'll spare
> you
> > the pros and cons.
>
> I still see more cons than pros for moving to Maven.
>
> It (mostly) works now and allows behaving better with bigger projects. IMO
it is unavoidable now.
Rémy
Re: Git
Posted by Mark Thomas <ma...@apache.org>.
On 21/01/2014 10:18, Rémy Maucherat wrote:
> 2014/1/21 Mark Thomas <ma...@apache.org>
>> Thoughts?
>>
>
> Risky, but it can be attempted. I'm not very familiar with the
> infrastructure used though. git.apache.org is there already, it mirrors
> svn, and it is then mirrored again in github ? The repo to do the commits
> would then be git.apache.org ?
Yes, git.a.o would become the master repo (or maybe git-wip.a.o) and
that would be mirrored to github. svn would be made read-only and would
not be updated any further.
> Since we're considering big changes, what about Maven too ? I'll spare you
> the pros and cons.
I still see more cons than pros for moving to Maven.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Git
Posted by Mark Thomas <ma...@apache.org>.
On 21/01/2014 12:27, Olivier Lamy wrote:
> I wonder if this could improve a bit the modularity of the various
> jars we deploy. Especially for the embeded part. (maybe could prevent
> issues as: jsp/jasper is mandatory to run embeded mode even if you
> don't use it)
The modularity is not the issue there. The issue is how we choose to
package things for embedded and the build system wouldn't have changed that.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Git
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hi
just a side note about maven from a tomee dev (and big tomcat user ;):
would be great to make it easier to build for anyone but it would
mandate to be useful to restructure tomcat sources to be modular as
well which would be really great IMO!
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2014/1/21 Olivier Lamy <ol...@apache.org>:
> On 21 January 2014 21:18, Rémy Maucherat <re...@apache.org> wrote:
>> 2014/1/21 Mark Thomas <ma...@apache.org>
>>
>>> On the down side:
>>> - there is much more potential to mess things up
>>>
>>
>> Yes, I can help with that if you want :)
>>
>>
>>> - cleaning up is potentially more complex
>>> - the disruption of the move - particularly if we want to move to a
>>> single git repo - could be significant
>>>
>>>
>>> Thoughts?
>>>
>
> Very good idea!
>
>>
>> Risky, but it can be attempted. I'm not very familiar with the
>> infrastructure used though. git.apache.org is there already, it mirrors
>> svn, and it is then mirrored again in github ? The repo to do the commits
>> would then be git.apache.org ?
>>
>> Since we're considering big changes, what about Maven too ? I'll spare you
>> the pros and cons.
>
> I wonder if this could improve a bit the modularity of the various
> jars we deploy. Especially for the embeded part. (maybe could prevent
> issues as: jsp/jasper is mandatory to run embeded mode even if you
> don't use it)
>
>>
>> Rémy
>
>
>
> --
> Olivier Lamy
> Ecetera: http://ecetera.com.au
> http://twitter.com/olamy | http://linkedin.com/in/olamy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Git
Posted by Olivier Lamy <ol...@apache.org>.
On 21 January 2014 21:18, Rémy Maucherat <re...@apache.org> wrote:
> 2014/1/21 Mark Thomas <ma...@apache.org>
>
>> On the down side:
>> - there is much more potential to mess things up
>>
>
> Yes, I can help with that if you want :)
>
>
>> - cleaning up is potentially more complex
>> - the disruption of the move - particularly if we want to move to a
>> single git repo - could be significant
>>
>>
>> Thoughts?
>>
Very good idea!
>
> Risky, but it can be attempted. I'm not very familiar with the
> infrastructure used though. git.apache.org is there already, it mirrors
> svn, and it is then mirrored again in github ? The repo to do the commits
> would then be git.apache.org ?
>
> Since we're considering big changes, what about Maven too ? I'll spare you
> the pros and cons.
I wonder if this could improve a bit the modularity of the various
jars we deploy. Especially for the embeded part. (maybe could prevent
issues as: jsp/jasper is mandatory to run embeded mode even if you
don't use it)
>
> Rémy
--
Olivier Lamy
Ecetera: http://ecetera.com.au
http://twitter.com/olamy | http://linkedin.com/in/olamy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Git
Posted by Rémy Maucherat <re...@apache.org>.
2014/1/21 Mark Thomas <ma...@apache.org>
> On the down side:
> - there is much more potential to mess things up
>
Yes, I can help with that if you want :)
> - cleaning up is potentially more complex
> - the disruption of the move - particularly if we want to move to a
> single git repo - could be significant
>
>
> Thoughts?
>
Risky, but it can be attempted. I'm not very familiar with the
infrastructure used though. git.apache.org is there already, it mirrors
svn, and it is then mirrored again in github ? The repo to do the commits
would then be git.apache.org ?
Since we're considering big changes, what about Maven too ? I'll spare you
the pros and cons.
Rémy
Re: Git
Posted by Jeremy Boynes <jb...@apache.org>.
On Jan 21, 2014, at 1:58 AM, Mark Thomas <ma...@apache.org> wrote:
> I've been using Git more and more for Tomcat development and was
> wondering what folks thought about moving Tomcat to git. This isn't a
> formal proposal or a vote, I'm just trying to gather some views.
>
> On the plus side:
> - it is much easier to have multiple issues in progress at the
> same time and switch between them
> - being able to work off-line but still commit is a huge benefit
> when working on a complex issue and you don't have internet
> access
> - merging between branches (assuming all supported branches were in a
> single repo) is simpler
>
> Neutral
> - we would need to agree some simple guidelines for how we used git
> - tooling seems equivalent to that available for svn (at for what I
> use anyway)
>
> On the down side:
> - there is much more potential to mess things up
> - cleaning up is potentially more complex
> - the disruption of the move - particularly if we want to move to a
> single git repo - could be significant
>
>
> Thoughts?
Generally +0
I think the ability to work offline on multiple issues can be a double edged sword. I just did that this week and having Git would have been helpful. The downside is that it makes it easier to work more in isolation rather than collaborating with other developers. In a quick experiment, I tried Git with some cookie changes and now have a series of changes to merge in one go rather than incrementally and I think that will be harder to review.
Having said that, this may just be an artifact of using git with svn as I think if the primary repo was natively Git then I would have done that work in a feature branch in the shared repo.
I’ve not followed this on infra@ but from what I understand the web tooling at Apache lags behind SVN's. There’s a richer interface at GitHub but that’s moving yet more away from the Apache community. I’ve found the web view very useful when working with people who are not engaged in the project on a regular basis.
—
Jeremy
Re: Git
Posted by Henri Gomez <he...@gmail.com>.
>> - Oliver's project to convert Tomcat build to Maven was not a success
>
> I started but this change need a bit support so perso I don't want to
> spend time if lack of interest.
it make sense ;(
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Git
Posted by Olivier Lamy <ol...@apache.org>.
On 21 January 2014 23:42, Konstantin Kolinko <kn...@gmail.com> wrote:
> 2014/1/21 Mark Thomas <ma...@apache.org>:
>> I've been using Git more and more for Tomcat development and was
>> wondering what folks thought about moving Tomcat to git. This isn't a
>> formal proposal or a vote, I'm just trying to gather some views.
>>
>> On the plus side:
>> - it is much easier to have multiple issues in progress at the
>> same time and switch between them
>> - being able to work off-line but still commit is a huge benefit
>> when working on a complex issue and you don't have internet
>> access
>> - merging between branches (assuming all supported branches were in a
>> single repo) is simpler
>>
>> Neutral
>> - we would need to agree some simple guidelines for how we used git
>> - tooling seems equivalent to that available for svn (at for what I
>> use anyway)
>
> Regarding the tools:
>
> 1. In my experience it was harder to review history of some project
> hosted on github than one using subversion.
>
> (Using only web tools such as viewvc log & annotate pages).
>
> It is more to the nature of git itself, as the recommended "Feature
> branches" approach makes so that most of merges to master branch are
> collections of several other commits at elsewhere. It is harder to
> review the tree.
>
> 2. Buildbot uses subversion revision number as identifier (when
> building and when publishing logs).
>
> 3. We have references to revision numbers in our commit messages.
>
>> On the down side:
>> - there is much more potential to mess things up
>> - cleaning up is potentially more complex
>> - the disruption of the move - particularly if we want to move to a
>> single git repo - could be significant
>
> 4. IIUC, the current Tomcat6/7/trunk mirrors at github does not comply
> to this "single repo" condition?
>
> 5. Subversion does not allow deleting files from the past history (a
> long wanted 'obliterate' feature).
>
> Git does allow such deletion (so you can mess your history fatally).
> Disclaimer: I do not such experience with git, so I cannot assess
> whether it is easy to trigger this deletion or easy to prevent it from
> administrators' side.
>
> In Jenkins project there was some incident with Git several months ago.
> http://jenkins-ci.org/content/summary-report-git-repository-disruption-incident-nov-10th
>
> 6. Overall, I have some frustration with the direction where Apache
> Subversion project itself is going, but I am not brave enough to hop
> to Git.
>
> My "vote" is -0.
>
> 7. -1 for Maven.
>
> The arguments were stated in old discussions.
> My main ones
> - I like the single source tree that we have now
> - Oliver's project to convert Tomcat build to Maven was not a success
I started but this change need a bit support so perso I don't want to
spend time if lack of interest.
>
> 2014/1/21 Rémy Maucherat <re...@apache.org>:
>>>
>>> I still see more cons than pros for moving to Maven.
>>>
>>> It (mostly) works now and allows behaving better with bigger projects. IMO
>> it is unavoidable now.
>
> Spring Framework is a big project, but it uses Gradle, not Maven.
> https://github.com/spring-projects/spring-framework#building-from-source
>
> Best regards,
> Konstantin Kolinko
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
--
Olivier Lamy
Ecetera: http://ecetera.com.au
http://twitter.com/olamy | http://linkedin.com/in/olamy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Git
Posted by Konstantin Kolinko <kn...@gmail.com>.
2014/1/21 Mark Thomas <ma...@apache.org>:
> I've been using Git more and more for Tomcat development and was
> wondering what folks thought about moving Tomcat to git. This isn't a
> formal proposal or a vote, I'm just trying to gather some views.
>
> On the plus side:
> - it is much easier to have multiple issues in progress at the
> same time and switch between them
> - being able to work off-line but still commit is a huge benefit
> when working on a complex issue and you don't have internet
> access
> - merging between branches (assuming all supported branches were in a
> single repo) is simpler
>
> Neutral
> - we would need to agree some simple guidelines for how we used git
> - tooling seems equivalent to that available for svn (at for what I
> use anyway)
Regarding the tools:
1. In my experience it was harder to review history of some project
hosted on github than one using subversion.
(Using only web tools such as viewvc log & annotate pages).
It is more to the nature of git itself, as the recommended "Feature
branches" approach makes so that most of merges to master branch are
collections of several other commits at elsewhere. It is harder to
review the tree.
2. Buildbot uses subversion revision number as identifier (when
building and when publishing logs).
3. We have references to revision numbers in our commit messages.
> On the down side:
> - there is much more potential to mess things up
> - cleaning up is potentially more complex
> - the disruption of the move - particularly if we want to move to a
> single git repo - could be significant
4. IIUC, the current Tomcat6/7/trunk mirrors at github does not comply
to this "single repo" condition?
5. Subversion does not allow deleting files from the past history (a
long wanted 'obliterate' feature).
Git does allow such deletion (so you can mess your history fatally).
Disclaimer: I do not such experience with git, so I cannot assess
whether it is easy to trigger this deletion or easy to prevent it from
administrators' side.
In Jenkins project there was some incident with Git several months ago.
http://jenkins-ci.org/content/summary-report-git-repository-disruption-incident-nov-10th
6. Overall, I have some frustration with the direction where Apache
Subversion project itself is going, but I am not brave enough to hop
to Git.
My "vote" is -0.
7. -1 for Maven.
The arguments were stated in old discussions.
My main ones
- I like the single source tree that we have now
- Oliver's project to convert Tomcat build to Maven was not a success
2014/1/21 Rémy Maucherat <re...@apache.org>:
>>
>> I still see more cons than pros for moving to Maven.
>>
>> It (mostly) works now and allows behaving better with bigger projects. IMO
> it is unavoidable now.
Spring Framework is a big project, but it uses Gradle, not Maven.
https://github.com/spring-projects/spring-framework#building-from-source
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org