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 reference?)
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?)
3). The plan to create a Maven build (BZ 56397) relies on svn externals.
(I think it is time to abandon the idea.)
6. Maybe move away modules/bayeux and modules/tomcat-lite ?
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
