[infinispan-dev] Running the testsuite and being able to work with IDE

[Galder Zamarreño]

On Mar 21, 2012, at 9:03 PM, Sanne Grinovero wrote:

> On 21 March 2012 16:42, Galder Zamarreño <galder at redhat.com> wrote:
>> 
>> On Mar 21, 2012, at 11:11 AM, Sanne Grinovero wrote:
>> 
>>> I'm not sure how you could have missed all the times I mention this
>>> script from Emmanuel ;-)
>>> 
>>> https://gist.github.com/789588
>> 
>> I've seen it and the script several times and no matter how many times I look at it, I still don't see how it fits my use case.
> 
> It could help giving it a try rather than looking at it :D

Well, I can read what it does and if I find it not to be useful, I wont waste my time trying it :D

> 
>> 
>> I've always understood that Emmanuel's script works with committed changes and clones a repo and that's not what I want for a couple of reasons:
>> 
>> 1. Just want to uncommitted test changes.
> 
> I guess that's the main point on which our opinions diverge. This
> means the pull requests you send are not what you have tested, as you
> might have an index in different state.
> We consider it a big value to test only what's committed.

Although I think it's a valid point, the sync_with_upstream patch we have will stash changes, synch up and then reapply. And I use that script frequent enough that I haven't had any issues that you suggest.

> 
> This makes me think you blindly "add all" to avoid mistakes: likely
> again matter of taste, but I think that approach is not encouraging
> better looking patches.

"add all" to avoid which mistakes? what do you mean by "add all"?

Indeed, I think this is more a divergence in taste/habit, which Emmanuel clarifies further in the next email. 

However, all this is good to find out about different approaches.

> 
>> 2. I don't want the copy to be clone in order to avoid committing things in the wrong place.
> 
> You could export rather than clone, but I don't feel your need as this
> clone is going to happen to a path which your nor your IDE nor your
> terminal are pointing to.

Well, I do run it from ~/Go/test/infinispan.git, so that I can see the failures and have quicker access to the folder if I need to…etc, so my terminal is pointing to it.

I could do it the other way too.

> 
> 
>> Feel free to correct me….
>> 
>>> And this one is from myself, also useful imho:
>>> 
>>> https://gist.github.com/1086445
>> 
>> Hmmm, how far does it go opening JIRAs? I mean, if I integrate ISPN-9999, I don't want all past JIRAs to open, just ISPN-9999.
> 
> Why would it open all previous issues?
> It only looks at the history of commits between HEAD and master,
> usually no more than a dozen of commits, and extracts identifiers
> which look like JIRA issue codes.
> Granted it works only for branches "targeting" master, don't use it
> when reviewing [for example] a commit backported to 5.1.x.

I'm not saying that it will open all previous issues, I was more wondering about how it does it to avoid opening all previous issues..

> 
>> 
>> I use Chrome btw.
> 
> sorry to hear Chrome can't open JIRA ..

:)

> 
>> 
>>> Both have been promoted as global alias in my shells since a while.
>>> 
>>> Sanne
>>> 
>>> On 21 March 2012 09:50, Galder Zamarreño <galder at redhat.com> wrote:
>>>> Hi all,
>>>> 
>>>> Just wanted to share a tip that's helped me in the last few months get more productive
>>>> 
>>>> You might have seen that once you run the testsuite in the infinispan source code, IntelliJ kinda goes a bit mad re-indexing and the IDE becomes unusable.
>>>> 
>>>> Eventually I got fed up of this and what I do instead is rsync to a separate folder with:
>>>> 
>>>> rsync -av --exclude '.git' --exclude '*.class' --exclude 'target' --delete ~/Go/code/infinispan.git/ .
>>>> 
>>>> I do this from say: ~/Go/test/infinispan.git which crucially is not a git clone which avoids accidental commits from that folder.
>>>> 
>>>> Then, I always run the testsuite from that test folder after rsyncing. That way, I can carry on doing stuff in the IDE while the testsuite runs in the background.
>>>> 
>>>> Having SSD and 8gb ram help of course too :)
>>>> 
>>>> Cheers,
>>>> 
>>>> p.s. If you have any other tips that have helped you, please share.
>>>> --
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache