7:06 a.m.
On Mar 21, 2012, at 9:03 PM, Sanne Grinovero wrote:
On 21 March 2012 16:42, Galder Zamarreño <galder(a)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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache