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

[Emmanuel Bernard]

I do tend to commit often and rebase/amend if needed. It helps minimize context switching. 
The big plus for me is that I can work on the next thing while tests are running. 

I never have my command line in the cloned repo so I can never commit to the wrong repo. 

Btw you can ask IntelliJ to exclude some directories from scanning but that's a manual setup I believe. 

On 21 mars 2012, at 21:03, Sanne Grinovero <sanne at infinispan.org> 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
> 
>> 
>> 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.
> 
> 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.
> 
>> 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.
> 
> 
>> 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 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