Git and eZ Approve 2: checking in
My membership of the eZ Approve 2 project has been given the green light so as a follow up to my previous post Using Git with eZ Publish projects I can present the output of the commits back to the subversion repository.
Checking the log of the subversion repository shows each of the local git commits as individual subversion commits along with there respective commit log messages.
For all intents and purposes it's undetectable the other repository users that anything out of the ordinary has gone on.
A couple of the comments to the previous post pointed out alternatives to git:
I don't have the inclination to check them all out, especially given that git meets my requirements.
If you want some more info Dave Dribin has a couple of blog posts that contain a review of Git, Bazzar & Mercurial, and a explanation as to why he choose Mercurial. Dave says that in the end it was a gut choice and that for projects where "I still have to use Subversion, I will be using git-svn".
$ git-svn dcommit
Authentication realm: eZ projects
Password for 'zabbie':
A design/standard/templates/node/view/plain.tpl
Committed r2501
M eventtypes/event/ezapprove2/ezapprove2type.php
Committed r2502
M classes/ezxapprovestatususerlink.php
Committed r2503
M collaboration/ezapprove2/ezapprove2collaborationhandler.php
Committed r2504
M collaboration/ezapprove2/ezapprove2collaborationhandler.php
Committed r2505
A design/standard/templates/node/view/plain.tpl
r2501 = e5a186160c1fab07a2894d180f932e3a6931b782 (git-svn)
M eventtypes/event/ezapprove2/ezapprove2type.php
r2502 = 43c5b3ba16bf4015ee8f9c2f2a1a9e4d4333972d (git-svn)
M classes/ezxapprovestatususerlink.php
r2503 = be6daf109a91319da0ee16c40b2344c0de18291d (git-svn)
M collaboration/ezapprove2/ezapprove2collaborationhandler.php
r2504 = 8113d8d1d58d92da6a4cee34c14b7d6db227ef86 (git-svn)
M collaboration/ezapprove2/ezapprove2collaborationhandler.php
r2505 = e9acd0e93e1c47dea1cd88a47b26e8b34a951552 (git-svn)
No changes between current HEAD and refs/remotes/git-svn
Resetting to the latest refs/remotes/git-svn
Checking the log of the subversion repository shows each of the local git commits as individual subversion commits along with there respective commit log messages.
$ svn log http://svn.projects.ez.no/ezapprove2 | head -n 30
------------------------------------------------------------------------
r2505 | zabbie | 2008-03-03 10:09:47 +1000 (Mon, 03 Mar 2008) | 2 lines
Fix for placement of a previously unpublished object that is edited
------------------------------------------------------------------------
r2504 | zabbie | 2008-03-03 10:09:37 +1000 (Mon, 03 Mar 2008) | 2 lines
Fixed method definitions to match eZCollaborationItemHandler to stop strict messages
------------------------------------------------------------------------
r2503 | zabbie | 2008-03-03 10:09:26 +1000 (Mon, 03 Mar 2008) | 2 lines
Corrected typo in const for role approver
------------------------------------------------------------------------
r2502 | zabbie | 2008-03-03 10:09:18 +1000 (Mon, 03 Mar 2008) | 2 lines
Typo in const
------------------------------------------------------------------------
r2501 | zabbie | 2008-03-03 10:09:06 +1000 (Mon, 03 Mar 2008) | 2 lines
fixed "Placed in:" for items previously unpublished
------------------------------------------------------------------------
r2500 | tw | 2008-01-15 02:15:14 +1000 (Tue, 15 Jan 2008) | 1 line
- Fixed missing static in ezinfo.php
------------------------------------------------------------------------
r2499 | (no author) | 2008-01-15 00:37:38 +1000 (Tue, 15 Jan 2008) | 1 line
For all intents and purposes it's undetectable the other repository users that anything out of the ordinary has gone on.
A couple of the comments to the previous post pointed out alternatives to git:
I don't have the inclination to check them all out, especially given that git meets my requirements.
If you want some more info Dave Dribin has a couple of blog posts that contain a review of Git, Bazzar & Mercurial, and a explanation as to why he choose Mercurial. Dave says that in the end it was a gut choice and that for projects where "I still have to use Subversion, I will be using git-svn".
Comments
Post a Comment