You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-dev@jackrabbit.apache.org by Francesco Mari <ma...@gmail.com> on 2018/12/10 09:58:10 UTC
Why don't we move to Git?
Given the recent announcement about gitbox.apache.org, the seamless
integration with GitHub, and the fact that many of us already work with Git
in our daily workflow, what about moving our repositories to Git?
Re: Why don't we move to Git?
Posted by Marcel Reutegger <mr...@adobe.com.INVALID>.
Hi,
I think this would be a good move. Today git seems to be more popular and powerful than svn. Currently we have people and tools using different SCM systems, which can sometimes be difficult and comes with a cost. I don't know how many times the GitHub mirror wasn't in sync anymore and manual intervention was necessary...
Regards
Marcel
On 10.12.18, 10:58, "Francesco Mari" <ma...@gmail.com> wrote:
Given the recent announcement about gitbox.apache.org, the seamless
integration with GitHub, and the fact that many of us already work with Git
in our daily workflow, what about moving our repositories to Git?
Re: Why don't we move to Git?
Posted by Davide Giannella <da...@apache.org>.
On 11/12/2018 10:10, Francesco Mari wrote:
> Hi,
>
> On Tue, 11 Dec 2018 at 10:56, Davide Giannella <da...@apache.org> wrote:
>
>> Does git change always HEAD? Even if you merge something that fits
>> "behind" HEAD.
>>
> Git always changes the head when a merge commit is performed. See [1] for
> more details about how merging works in Git. I hope I understood your
> concerns right.
+1 then on this aspect. :)
D.
Re: Why don't we move to Git?
Posted by Francesco Mari <ma...@gmail.com>.
Hi,
On Tue, 11 Dec 2018 at 10:56, Davide Giannella <da...@apache.org> wrote:
> Does git change always HEAD? Even if you merge something that fits
> "behind" HEAD.
>
Git always changes the head when a merge commit is performed. See [1] for
more details about how merging works in Git. I hope I understood your
concerns right.
[1]: https://www.atlassian.com/git/tutorials/using-branches/git-merge
Re: Why don't we move to Git?
Posted by Davide Giannella <da...@apache.org>.
Hello Fra,
On 10/12/2018 14:28, Francesco Mari wrote:
> Using a version composed by based version, timestamp and commit hash works
> well. The qualifier is compared lexicographically, so the timestamp would
> do the trick regardless of the commit hash. See this example [1] on
> Versionatorr.
you put
1.0-20181210-79377d5aab231f27fa7e3dc7bdd0e828
1.0-20181209-8135fa0dc4bdb394f38afc1f084336a2
which are two different timestamps. I didn't look yet at the details nor
if this *would actually happen*
*Release 1*
HEAD 20121210
|
|
...
Will produce X.Y-20121210-79377d
*Release 2*
We want to release something that has just been merged but the merge
doesn't move HEAD
HEAD 20121210
|
| \
| \ BRANCH 20121215 8135fa0dc
... ...
Will produce again X.Y-20121210-79377d but in fact are two different
binaries.
Does git change always HEAD? Even if you merge something that fits
"behind" HEAD.
Davide
Re: Why don't we move to Git?
Posted by Francesco Mari <ma...@gmail.com>.
Hi,
On Mon, 10 Dec 2018 at 15:19, Davide Giannella <da...@apache.org> wrote:
> Another point to keep in mind is the version number for diagnostic
> builds[0]. So far we used the SVN revision which is unique and
> incremental. This works perfectly in the OSGi world making sure any
> diagnostic build will apply as planned. If moving to git purely, commits
> are tracked as SHA and I don't think the incremental version aspect can
> be enforced the same way.
>
> 0) http://jackrabbit.apache.org/oak/docs/diagnostic-builds.html
>
> We have to find a way to achieve the same when moving to git. Probably
> by appending the full timestamp of the commit or some other form of time
> related information. It probably won't be enough as if someone merge in
> a commit "older" than the current HEAD, re-releasing a diagnostic build
> will produce the same timestamp.
>
> Again, just quickly crushing my head on it, we could work out something
> with the release-plugin skipping the tagging, but adding a commit every
> time before we produce a diagnostic build.
>
> Something to be investigated.
>
Using a version composed by based version, timestamp and commit hash works
well. The qualifier is compared lexicographically, so the timestamp would
do the trick regardless of the commit hash. See this example [1] on
Versionatorr.
[1]:
http://versionatorr.appspot.com/?a=1.0-20181210-79377d5aab231f27fa7e3dc7bdd0e828&b=1.0-20181209-8135fa0dc4bdb394f38afc1f084336a2
Re: Why don't we move to Git?
Posted by Davide Giannella <da...@apache.org>.
hello,
+1 for the move (after Christmas). See in-line
On 10/12/2018 12:39, Francesco Mari wrote:
> Hi,
>
> On Mon, 10 Dec 2018 at 11:45, Robert Munteanu <ro...@apache.org> wrote:
>
>> - one repository for Oak or one repository per module (oak-commons,
>> oak-api, etc )?
>>
> I don't think we should change the structure of the repository during the
> migration. I would maintain one single repository for Oak.
+1
>
>> - how does this tie into the potential modularisation work?
>>
> The migration to Git and the modularisation work look orthogonal to me.
+1
>
>
>> - who will do the work for migrating repositories, release scripts,
>> Jenkins setup, etc?
>>
> I'm willing to drive the effort if we decide to go further. Before the
> migration we should come up with a list of consumers of the SVN repository
> and figure out the amount of additional work after the migration.
probably is mainly jenkins and github. We could make it clearer by
advertising officially the move and see if any other consumer comes up.
Another point to keep in mind is the version number for diagnostic
builds[0]. So far we used the SVN revision which is unique and
incremental. This works perfectly in the OSGi world making sure any
diagnostic build will apply as planned. If moving to git purely, commits
are tracked as SHA and I don't think the incremental version aspect can
be enforced the same way.
0) http://jackrabbit.apache.org/oak/docs/diagnostic-builds.html
We have to find a way to achieve the same when moving to git. Probably
by appending the full timestamp of the commit or some other form of time
related information. It probably won't be enough as if someone merge in
a commit "older" than the current HEAD, re-releasing a diagnostic build
will produce the same timestamp.
Again, just quickly crushing my head on it, we could work out something
with the release-plugin skipping the tagging, but adding a commit every
time before we produce a diagnostic build.
Something to be investigated.
>
>
>> - what is the transition plan for the SVN repositories and what will
>> happen to the existing github mirrors?
>>
> I would leave the SVN repository in read-only mode after the migration. The
> GitHub mirror should be replaced by the migrated repository.
+1
Davide
Re: Why don't we move to Git?
Posted by Francesco Mari <ma...@gmail.com>.
Hi,
On Mon, 10 Dec 2018 at 11:45, Robert Munteanu <ro...@apache.org> wrote:
> - one repository for Oak or one repository per module (oak-commons,
> oak-api, etc )?
>
I don't think we should change the structure of the repository during the
migration. I would maintain one single repository for Oak.
> - how does this tie into the potential modularisation work?
>
The migration to Git and the modularisation work look orthogonal to me.
> - who will do the work for migrating repositories, release scripts,
> Jenkins setup, etc?
>
I'm willing to drive the effort if we decide to go further. Before the
migration we should come up with a list of consumers of the SVN repository
and figure out the amount of additional work after the migration.
> - what is the transition plan for the SVN repositories and what will
> happen to the existing github mirrors?
>
I would leave the SVN repository in read-only mode after the migration. The
GitHub mirror should be replaced by the migrated repository.
> (and probably some I'm missing)
>
We are probably going to meet other bumpers down the road. For the moment
I'm interested in collecting the opinions of the team.
Re: Why don't we move to Git?
Posted by Francesco Mari <ma...@gmail.com>.
Hi,
On Mon, 10 Dec 2018 at 12:08, Julian Reschke <ju...@gmx.de> wrote:
> They already provide patches through Github, right?
Those patches have the be brought back into SVN. This requires some manual
work. It's not a lot, but it's not as seamless as it could be.
> I don't see anything broken with the current SVN setup, but lots of work
> moving over to Git.
>
There is nothing broken with SVN. I'm just figuring out if the team is
willing to sustain some disruption for migrating to Git. If that's not the
case, we can just leave things as they are.
(Just my 2 cents, of course)
>
Every point of view needs to be taken into account. We all need to be on
board before taking any considerable step.
Re: Why don't we move to Git?
Posted by Julian Reschke <ju...@gmx.de>.
On 2018-12-10 11:49, Michael Dürig wrote:
> +1 I think moving to Git would eventually simplify a few things.
"eventually".
> Especially ramping up new committers and sporadic contributors will
> likely find it easier through Git.
They already provide patches through Github, right?
> Robert already brought up some issues we need keep in mind when
> migrating and I'm sure there are more. Let's see whether we can get a
> rough consensus first on whether we want to move in the next couple of
> months before delving too deep into technical issues.
I don't see anything broken with the current SVN setup, but lots of work
moving over to Git.
(Just my 2 cents, of course)
Best regards, Julian
Re: Why don't we move to Git?
Posted by Michael Dürig <md...@apache.org>.
+1 I think moving to Git would eventually simplify a few things.
Especially ramping up new committers and sporadic contributors will
likely find it easier through Git.
Robert already brought up some issues we need keep in mind when
migrating and I'm sure there are more. Let's see whether we can get a
rough consensus first on whether we want to move in the next couple of
months before delving too deep into technical issues.
Michael
On Mon, 10 Dec 2018 at 11:45, Robert Munteanu <ro...@apache.org> wrote:
>
> Hi Francesco,
>
> On Mon, 2018-12-10 at 10:58 +0100, Francesco Mari wrote:
> > Given the recent announcement about gitbox.apache.org, the seamless
> > integration with GitHub, and the fact that many of us already work
> > with Git
> > in our daily workflow, what about moving our repositories to Git?
>
> Well, I'm all for it, but there are many details to be filled in ...
>
> - one repository for Oak or one repository per module (oak-commons,
> oak-api, etc )?
> - how does this tie into the potential modularisation work?
> - who will do the work for migrating repositories, release scripts,
> Jenkins setup, etc?
> - what is the transition plan for the SVN repositories and what will
> happen to the existing github mirrors?
>
> (and probably some I'm missing)
>
> Thanks,
>
> Robert
>
Re: Why don't we move to Git?
Posted by Robert Munteanu <ro...@apache.org>.
Hi Francesco,
On Mon, 2018-12-10 at 10:58 +0100, Francesco Mari wrote:
> Given the recent announcement about gitbox.apache.org, the seamless
> integration with GitHub, and the fact that many of us already work
> with Git
> in our daily workflow, what about moving our repositories to Git?
Well, I'm all for it, but there are many details to be filled in ...
- one repository for Oak or one repository per module (oak-commons,
oak-api, etc )?
- how does this tie into the potential modularisation work?
- who will do the work for migrating repositories, release scripts,
Jenkins setup, etc?
- what is the transition plan for the SVN repositories and what will
happen to the existing github mirrors?
(and probably some I'm missing)
Thanks,
Robert
Re: Why don't we move to Git?
Posted by Konrad Windszus <kw...@apache.org>.
Almost two years later, I volunteer to do the move. I am gonna start a vote in a separate thread.
On 2019/07/23 17:15:03, Konrad Windszus <kw...@apache.org> wrote:
> Was there any consensus reached and is it planned to be tackled soon?
>
> On 2018/12/12 23:35:42, Matt Ryan <ma...@apache.org> wrote:
> > I'm +1; as Davide said, after Christmas :)
> >
> > Working out details seems like a good topic for an upcoming Oakathon,
> > assuming the general feeling is in favor of the change.
> >
> > -MR
> >
> > On Mon, Dec 10, 2018 at 2:58 AM Francesco Mari <ma...@gmail.com>
> > wrote:
> >
> > > Given the recent announcement about gitbox.apache.org, the seamless
> > > integration with GitHub, and the fact that many of us already work with Git
> > > in our daily workflow, what about moving our repositories to Git?
> > >
> >
>
Re: Why don't we move to Git?
Posted by Konrad Windszus <kw...@apache.org>.
Was there any consensus reached and is it planned to be tackled soon?
On 2018/12/12 23:35:42, Matt Ryan <ma...@apache.org> wrote:
> I'm +1; as Davide said, after Christmas :)
>
> Working out details seems like a good topic for an upcoming Oakathon,
> assuming the general feeling is in favor of the change.
>
> -MR
>
> On Mon, Dec 10, 2018 at 2:58 AM Francesco Mari <ma...@gmail.com>
> wrote:
>
> > Given the recent announcement about gitbox.apache.org, the seamless
> > integration with GitHub, and the fact that many of us already work with Git
> > in our daily workflow, what about moving our repositories to Git?
> >
>
Re: Why don't we move to Git?
Posted by Matt Ryan <ma...@apache.org>.
I'm +1; as Davide said, after Christmas :)
Working out details seems like a good topic for an upcoming Oakathon,
assuming the general feeling is in favor of the change.
-MR
On Mon, Dec 10, 2018 at 2:58 AM Francesco Mari <ma...@gmail.com>
wrote:
> Given the recent announcement about gitbox.apache.org, the seamless
> integration with GitHub, and the fact that many of us already work with Git
> in our daily workflow, what about moving our repositories to Git?
>