You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Jochen Wiedmann <jo...@gmail.com> on 2016/07/15 07:29:34 UTC
[RESULT] Migrate Apache Commons Fileupload to Git
Hi,
for the record: This vote has passes with three binding votes (Gary,
Stian, myself). I am ignoring the opposition voiced by Konstantin
Kolinko, because I don't think. that Tomcat's got a say. Besides,
there are several options, that Tomcat can follow:
1.) Use a shaded release jar, rather than forked sources.
2.) Migrate to git itself. This should actually simplify maintenance
of the current fork.
Jochen
--
The next time you hear: "Don't reinvent the wheel!"
http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [RESULT] Migrate Apache Commons Fileupload to Git
Posted by Mark Thomas <ma...@apache.org>.
On 18 July 2016 07:54:36 CEST, Jochen Wiedmann <jo...@gmail.com> wrote:
>On Fri, Jul 15, 2016 at 7:47 PM, Matt Sicker <bo...@gmail.com> wrote:
>> They can use the svn mirror on GitHub, too, unless that's against
>Apache
>> policy.
>
>
>Assuming that you are talking about the Tomcat "fork" (it really
>isn't, because there is no development happening, as far as I am
>aware, only pulling from Commons): My guess is that such a "mirror"
>doesn't contain svn:mergeinfo, thus won't be of any help.
Tomcat will probably just take diffs from git and apply the diffs to Tomcat's packaged renamed copy.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [RESULT] Migrate Apache Commons Fileupload to Git
Posted by Jochen Wiedmann <jo...@gmail.com>.
On Fri, Jul 15, 2016 at 7:47 PM, Matt Sicker <bo...@gmail.com> wrote:
> They can use the svn mirror on GitHub, too, unless that's against Apache
> policy.
Assuming that you are talking about the Tomcat "fork" (it really
isn't, because there is no development happening, as far as I am
aware, only pulling from Commons): My guess is that such a "mirror"
doesn't contain svn:mergeinfo, thus won't be of any help.
Jochen
--
The next time you hear: "Don't reinvent the wheel!"
http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [RESULT] Migrate Apache Commons Fileupload to Git
Posted by Matt Sicker <bo...@gmail.com>.
They can use the svn mirror on GitHub, too, unless that's against Apache
policy.
On 15 July 2016 at 02:29, Jochen Wiedmann <jo...@gmail.com> wrote:
> Hi,
>
> for the record: This vote has passes with three binding votes (Gary,
> Stian, myself). I am ignoring the opposition voiced by Konstantin
> Kolinko, because I don't think. that Tomcat's got a say. Besides,
> there are several options, that Tomcat can follow:
>
> 1.) Use a shaded release jar, rather than forked sources.
> 2.) Migrate to git itself. This should actually simplify maintenance
> of the current fork.
>
> Jochen
>
>
>
> --
> The next time you hear: "Don't reinvent the wheel!"
>
>
> http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
Matt Sicker <bo...@gmail.com>
Re: [RESULT] Migrate Apache Commons Fileupload to Git
Posted by Konstantin Kolinko <kn...@gmail.com>.
2016-07-15 10:29 GMT+03:00 Jochen Wiedmann <jo...@gmail.com>:
> Hi,
>
> for the record: This vote has passes with three binding votes (Gary,
> Stian, myself). I am ignoring the opposition voiced by Konstantin
> Kolinko, because I don't think. that Tomcat's got a say. Besides,
> there are several options, that Tomcat can follow:
OK, agreed.
This "Tomcat's got a say" is a wrong wording. I am not Tomcat. We are
individuals here. PMC position is expressed via votes, or at least via
a discussion. There was none at dev@tomcat.
I am just stating a technical issue and that your change will impact a
neighbor project.
You may go on.
I think that the likely solution at Tomcat side will be to create a
"vendor" branch in ASF Subversion repository.
So instead of an in-house in-tree merge there will be a copy of the
code, and some manual work to update it.
There was no discussion at @tomcat ML on further steps yet. It is just
how such issues are usually solved
> 1.) Use a shaded release jar, rather than forked sources.
This relies on timely releases at Commons side. It is also likely to
delay important fixes by several days.
Tomcat used build-time shading for Commons Pool and Commons DBCP, but
it switched to a fork at DBCP 2 time. One reason was that DBCP2 was in
active development and there were no releases for awhile.
Shading is used to avoid conflict with libraries used in web
applications deployed on Tomcat.
> Matt wrote:
> They can use the svn mirror on GitHub, too, unless that's against Apache
> policy.
Maybe.
I just tested that "svn ls", "svn log", "svn diff -c" on
https://github.com/apache/commons-fileupload.git are working.
E.g.
svn log --limit 10 https://github.com/apache/commons-fileupload.git/trunk/
"svn ls" is rather slow, but the two others are usable.
Thus it is possible to do svn merges from them. I do not know whether
those revision number are stable, though.
(I was more pessimistic
as my tests with svn log on GitHub two years ago were not successful.
It is good that it works.)
> 2.) Migrate to git itself. This should actually simplify maintenance
> of the current fork.
I do not think that migrating Tomcat will simplify maintenance. Is
there a good workflow, and support from tools?
A closing note:
To be compatible with Git, to be able to use Git and Subversion
interchangeably on the same sources, the only real requirement for a
project is to remove svn:keywords.
You will need to remove them anyway and I think it is a lot easier to
do so before svn-git migration.
http://svn.apache.org/viewvc?view=revision&revision=1561173
http://svn.apache.org/viewvc?view=revision&revision=1561174
For Tomcat I did it in two steps:
Step 1) search for $Id and remove those lines. Then search for '$' as
an additional check for missed keywords. Tomcat code had several
unusual keywords left from CVS time.
Step 2) svn propdel svn:keywords --depth infinity .
Use "svn status" or "svn diff" to verify changes before committing.
If "svn st" shows that some files have both metadata and content
changes, it means that those files were missed on step 1).
Sample output of "svn st", on a test repository, note the double "MM":
[[[
MM test.txt
]]]
"svn diff" shows the textual change:
[[[
Index: test.txt
===================================================================
--- test.txt (revision 54)
+++ test.txt (working copy)
@@ -1 +1 @@
-$Id$
+$Id: test.txt 54 2016-07-18 07:51:21Z kkolinko $
Property changes on: test.txt
___________________________________________________________________
Deleted: svn:keywords
## -1 +0,0 ##
-Id
\ No newline at end of property
]]]
Second, you can add ".gitignore" file. This is not required, but it is
rather convenient.
Tomcat did this and it can be developed in parallel using git or using svn,
There is no real need to migrate a project to git to be compatible
with git and to be able to accept pull requests.
I agree that migrating to git will make workflow easier. Thus I think
it will beneficial to your project.
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org