You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Adam Heath <do...@brainfood.com> on 2014/06/26 21:56:30 UTC
Git workflow discussion
Moving to the list, to discuss git.
Using the github url for git work, when you need to commit back into
svn, is not tenable. I don't think it necessary to rehash the reasons
why, it's a well known problem in the git-svn space.
However, if ofbiz switched to git, then what would be the procedure for
getting changes into the primary repo? Someone would have to take the
mantle.
Plus, with git, there could be commits that were authored by people who
had not signed a CLA.
On 06/26/2014 01:54 PM, Jacques Le Roux (JIRA) wrote:
> [ https://issues.apache.org/jira/browse/OFBIZ-5534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14045012#comment-14045012 ]
>
> Jacques Le Roux commented on OFBIZ-5534:
> ----------------------------------------
>
> I never tried, but then maybe there https://github.com/apache/ofbiz ?
>
>> Dirty reads from entity cache
>> -----------------------------
>>
>> Key: OFBIZ-5534
>> URL: https://issues.apache.org/jira/browse/OFBIZ-5534
>> Project: OFBiz
>> Issue Type: Bug
>> Components: framework
>> Affects Versions: Release Branch 11.04, SVN trunk, Release Branch 12.04, Release Branch 13.07
>> Reporter: Jacopo Cappellato
>> Assignee: Adam Heath
>> Attachments: unittest-dirtyreadsfromcache.patch
>>
>>
>> Even if database transaction isolation level is set to "ReadCommitted", a transaction can get uncommitted records from the entity cache, under certain circumstances.
>> Here is a test case:
>> 1) transaction T1 creates a record
>> 2) T1 calls findOne to retrieve it: the read will be successful (because T1 can read data generated in T1 even if not committed) and the record will be added to the cache
>> 3) T1 calls another service with requireNewTransaction set to true: this will run the second service in a new transaction T2
>> 4) T2 calls findOne to retrieve the record created by T1: if useCache is set to false it should fail; if useCache is set to true it will succeed (getting the record from cache, even if the data is not committed to the db)
>> The result in #4 is wrong because T2 should not see the uncommitted record
>> We should never add uncommitted records to the entity cache.
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.2#6252)
Re: Git workflow discussion
Posted by Jacques Le Roux <ja...@les7arts.com>.
One think I did, but it's not possible with apache.org's own git as it's currently organised, is to copy the .svn directory inside the git repository.
Then you have best of both world, quite convenient, I found not drawbacks so far.
Jacques
Le 27/06/2014 01:26, Adam Heath a écrit :
> That's the problem, using git for just this one problem.
>
> If you do things thru git, then eventually multiple people will have committed code into this new feature branch. After some amount of time, the
> branch will be done, and it'll be time to add it back to subversion.
>
> When this occurs, the author field in git will be thrown away, and whoever is doing the git-svn dcoommit will become the author; this is bad in
> apache land, as now the CLA comes into play. Aka, who authored the code?
>
> It will not be possible to do a git merge of the branch into a git-svn tracking branch, as then there will be a merge commit, and that will make
> git-svn barf.
>
> If the merged branch itself has merge commits(which it probably will), then the previous item is even more difficult.
>
> It's possible to squash the entire new branch, when adding it to the git-svn tracking branch, but that will also loose any authorship on the changes.
>
> ps: This has nothing to do with github, apache.org's own git, or any place else that hosts git repositories. It's a fundamental problem with the
> way git and svn manage changesets.
>
> pps: I just recently found this: If you cherry pick, your branch model is wrong <http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html>
>
> On 06/26/2014 03:32 PM, Jacques Le Roux wrote:
>> I was only suggesting for the problem at hand...
>>
>> Jacques
>
>
--
Re: Git workflow discussion
Posted by Adam Heath <do...@brainfood.com>.
That's the problem, using git for just this one problem.
If you do things thru git, then eventually multiple people will have
committed code into this new feature branch. After some amount of time,
the branch will be done, and it'll be time to add it back to subversion.
When this occurs, the author field in git will be thrown away, and
whoever is doing the git-svn dcoommit will become the author; this is
bad in apache land, as now the CLA comes into play. Aka, who authored
the code?
It will not be possible to do a git merge of the branch into a git-svn
tracking branch, as then there will be a merge commit, and that will
make git-svn barf.
If the merged branch itself has merge commits(which it probably will),
then the previous item is even more difficult.
It's possible to squash the entire new branch, when adding it to the
git-svn tracking branch, but that will also loose any authorship on the
changes.
ps: This has nothing to do with github, apache.org's own git, or any
place else that hosts git repositories. It's a fundamental problem with
the way git and svn manage changesets.
pps: I just recently found this: If you cherry pick, your branch model
is wrong
<http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html>
On 06/26/2014 03:32 PM, Jacques Le Roux wrote:
> I was only suggesting for the problem at hand...
>
> Jacques
Re: Git workflow discussion
Posted by Pierre Smits <pi...@gmail.com>.
The ASF has its own git setup. Have a look at:
http://git.apache.org/
https://git-wip-us.apache.org/
Apparently, both the repositories at the ASF and at GitHup are read-only.
Pierre
Pierre Smits
*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com
On Thu, Jun 26, 2014 at 10:32 PM, Jacques Le Roux <
jacques.le.roux@les7arts.com> wrote:
> I was only suggesting for the problem at hand...
>
> Jacques
>
>
> Le 26/06/2014 21:56, Adam Heath a écrit :
>
> Moving to the list, to discuss git.
>>
>> Using the github url for git work, when you need to commit back into svn,
>> is not tenable. I don't think it necessary to rehash the reasons why, it's
>> a well known problem in the git-svn space.
>>
>> However, if ofbiz switched to git, then what would be the procedure for
>> getting changes into the primary repo? Someone would have to take the
>> mantle.
>>
>> Plus, with git, there could be commits that were authored by people who
>> had not signed a CLA.
>>
>> On 06/26/2014 01:54 PM, Jacques Le Roux (JIRA) wrote:
>>
>>> [ https://issues.apache.org/jira/browse/OFBIZ-5534?page=
>>> com.atlassian.jira.plugin.system.issuetabpanels:comment-
>>> tabpanel&focusedCommentId=14045012#comment-14045012 ]
>>>
>>> Jacques Le Roux commented on OFBIZ-5534:
>>> ----------------------------------------
>>>
>>> I never tried, but then maybe there https://github.com/apache/ofbiz ?
>>>
>>> Dirty reads from entity cache
>>>> -----------------------------
>>>>
>>>> Key: OFBIZ-5534
>>>> URL: https://issues.apache.org/jira/browse/OFBIZ-5534
>>>> Project: OFBiz
>>>> Issue Type: Bug
>>>> Components: framework
>>>> Affects Versions: Release Branch 11.04, SVN trunk, Release Branch
>>>> 12.04, Release Branch 13.07
>>>> Reporter: Jacopo Cappellato
>>>> Assignee: Adam Heath
>>>> Attachments: unittest-dirtyreadsfromcache.patch
>>>>
>>>>
>>>> Even if database transaction isolation level is set to "ReadCommitted",
>>>> a transaction can get uncommitted records from the entity cache, under
>>>> certain circumstances.
>>>> Here is a test case:
>>>> 1) transaction T1 creates a record
>>>> 2) T1 calls findOne to retrieve it: the read will be successful
>>>> (because T1 can read data generated in T1 even if not committed) and the
>>>> record will be added to the cache
>>>> 3) T1 calls another service with requireNewTransaction set to true:
>>>> this will run the second service in a new transaction T2
>>>> 4) T2 calls findOne to retrieve the record created by T1: if useCache
>>>> is set to false it should fail; if useCache is set to true it will succeed
>>>> (getting the record from cache, even if the data is not committed to the db)
>>>> The result in #4 is wrong because T2 should not see the uncommitted
>>>> record
>>>> We should never add uncommitted records to the entity cache.
>>>>
>>>
>>>
>>> --
>>> This message was sent by Atlassian JIRA
>>> (v6.2#6252)
>>>
>>
>>
>>
> --
>
Re: Git workflow discussion
Posted by Jacques Le Roux <ja...@les7arts.com>.
I was only suggesting for the problem at hand...
Jacques
Le 26/06/2014 21:56, Adam Heath a écrit :
> Moving to the list, to discuss git.
>
> Using the github url for git work, when you need to commit back into svn, is not tenable. I don't think it necessary to rehash the reasons why,
> it's a well known problem in the git-svn space.
>
> However, if ofbiz switched to git, then what would be the procedure for getting changes into the primary repo? Someone would have to take the mantle.
>
> Plus, with git, there could be commits that were authored by people who had not signed a CLA.
>
> On 06/26/2014 01:54 PM, Jacques Le Roux (JIRA) wrote:
>> [
>> https://issues.apache.org/jira/browse/OFBIZ-5534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14045012#comment-14045012
>> ]
>>
>> Jacques Le Roux commented on OFBIZ-5534:
>> ----------------------------------------
>>
>> I never tried, but then maybe there https://github.com/apache/ofbiz ?
>>
>>> Dirty reads from entity cache
>>> -----------------------------
>>>
>>> Key: OFBIZ-5534
>>> URL: https://issues.apache.org/jira/browse/OFBIZ-5534
>>> Project: OFBiz
>>> Issue Type: Bug
>>> Components: framework
>>> Affects Versions: Release Branch 11.04, SVN trunk, Release Branch 12.04, Release Branch 13.07
>>> Reporter: Jacopo Cappellato
>>> Assignee: Adam Heath
>>> Attachments: unittest-dirtyreadsfromcache.patch
>>>
>>>
>>> Even if database transaction isolation level is set to "ReadCommitted", a transaction can get uncommitted records from the entity cache, under
>>> certain circumstances.
>>> Here is a test case:
>>> 1) transaction T1 creates a record
>>> 2) T1 calls findOne to retrieve it: the read will be successful (because T1 can read data generated in T1 even if not committed) and the record
>>> will be added to the cache
>>> 3) T1 calls another service with requireNewTransaction set to true: this will run the second service in a new transaction T2
>>> 4) T2 calls findOne to retrieve the record created by T1: if useCache is set to false it should fail; if useCache is set to true it will succeed
>>> (getting the record from cache, even if the data is not committed to the db)
>>> The result in #4 is wrong because T2 should not see the uncommitted record
>>> We should never add uncommitted records to the entity cache.
>>
>>
>> --
>> This message was sent by Atlassian JIRA
>> (v6.2#6252)
>
>
--