I see that the production and the staging are out of sync now and trying to
merge the upstream production leads to a merge commit.
How do we normally handle the cases when the production branch history
diverges from staging?
Vlad
On Thu, Jan 14, 2016 at 8:46 AM, Gunnar Morling
wrote:
> Davide
Hi,
On Thu, Jan 14, 2016 at 10:37:42AM +0200, Vlad Mihalcea wrote:
> I see that the production and the staging are out of sync now and trying to
> merge the upstream production leads to a merge commit.
>
> How do we normally handle the cases when the production branch history
> diverges from stag
Hi,
Thanks for the clarifications. I thought that forced push is disabled, but
that might be true for the ORM, OGM, etc projects only.
I was also using a separate branch for every post, but I was branching from
staging because that was the default branch I got when forking the repo.
I thought tho
> I thought those must be in-sync, like in a typical QA and production
> environment where you push changes from develop -> qa -> production
Staging can differ from production (usually be ahead) for previewing
changes. Then "releasing" is just a fast-forward merge from staging to
production. We do
The hibernate.org job is working now.
I probably changed the label to slave4 when doing some maintenance work and
forgot to put it back to OS1.
On Thu, Jan 14, 2016 at 9:31 AM, Gunnar Morling
wrote:
> > I thought those must be in-sync, like in a typical QA and production
> > environment whe
Hi,
> Personally, when using staging, I always try to leave it set to (or
> fast-forwardable to) production when I am done with a given authoring
> job. So the next guy coming after me doesn't have to care about any
> non-published commits on staging.
You are such a nice guy ;-)
--Hardy
pgpfn
That'd what I also aim for, but now because the staging and the production
are out-of-sync and I was branching from staging, I cherry picked from my
feature branch into production.
How do we handle this out-of-sync issue?
Do we have to rewrite the staging history to match production and force
push
Hi,
Since we are now moderating the forum and disallow new users from posting,
we can activate links on the forum to increase user experience.
What do you think?
Vlad
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/m
Hi,
> Do we have to rewrite the staging history to match production and force
> push it?
If you want staging to look like production, just push the production branch
onto staging.
$ git push -f origin production:staging
--Hardy
pgpFwAg64gDPO.pgp
Description: PGP signature
Thanks. The two branches are now in-sync.
Vlad
On Thu, Jan 14, 2016 at 2:22 PM, Hardy Ferentschik
wrote:
> Hi,
>
> > Do we have to rewrite the staging history to match production and force
> > push it?
>
> If you want staging to look like production, just push the production
> branch onto stagi
+1
On Thu, 14 Jan 2016 11:18 Vlad Mihalcea wrote:
> Hi,
>
> Since we are now moderating the forum and disallow new users from posting,
> we can activate links on the forum to increase user experience.
> What do you think?
>
> Vlad
> ___
> hibernate-de
Hi Steve,
One thing useful to have for OGM would be a generalization of the
hbm2ddl tooling so we can re-use it for managing NoSQL databases. Not
all of them are "schemaless", e.g. Cassandra works with a fixed
schema, and while MongoDB largely is schemaless, we still want to
create stuff like inde
The 7th bug fix release for ORM 5.0 has been released. For information, see
http://in.relation.to/2016/01/13/hibernate-orm-507-final-release/
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-d
+1
If they get abused we can always revert to the current state
On Thu, Jan 14, 2016 at 1:17 PM, Sanne Grinovero
wrote:
> +1
>
>
> On Thu, 14 Jan 2016 11:18 Vlad Mihalcea wrote:
>
> > Hi,
> >
> > Since we are now moderating the forum and disallow new users from
> posting,
> > we can activate l
So then it sounds like "no" to this, which is fine. We already have
updated to a much newer Ehcache and as pointed out earlier the stability in
the Ehcache API actually used in the integration means any 2.x version of
Ehcache should be fine to drop in.
Ehcache 3.x support will be based on that JS
I am not sure I am a big fan of The String->Object change specifically. In
theory it sounds great. But there is a major premise in schema tooling
around the idea of the actions being reduce-able to Strings. That's
important not just for SQL, but for the idea of writing to a file as well.
It also
Exactly,
I'm struggling to find a JSR-107 second-level cache to plug in my project.
EHCache 3.x does not integrate with hibernate yet, neither does hazelcast -
they have a PR, but they'll merge it in the next couple of months. Oracle
Coherence I think is paid, so is IBM extremescale and Grigain. J
Ehcache is all of those things iiuc. You are more than welcome to
help Louis, Alex, Sanne and the rest of us work on that JSR-107 based
integration to get it integrated sooner since its so important for you and
since its such a travesty ;)
On Thu, Jan 14, 2016 at 8:51 AM Steve Ebersole wrote:
Hi Petar,
Infinispan can work as a separate service, but that's not the default.
It's primarily designed for embedded caching, is OSS, implements
JSR-107 and also has integration helpers for Spring.
There are several other OSS implementations too; AFAIR cache2k is a
good one and also implements JS
Hi all,
I don't think it's a travesty - I actually use ehcache 2.x now :)
Thanks Sanne - I'll research infinispan more. One other thing - I see
there's a module hibernate-infinispan here:
http://repo1.maven.org/maven2/org/hibernate/hibernate-infinispan/
and inside I see they are using the 7.2.1.
The staging.hibernate.org should now work again,
It was a problem of permissions, the owner of the folder with the site
changed (not sure why) and the rsync script wasn't able to update it.
Davide
On Thu, Jan 14, 2016 at 1:15 PM, Vlad Mihalcea
wrote:
> Thanks. The two branches are now in-sync.
By the way, is there a way to recognize the staging website from the
production one?
If not we should probably add a timestamp somewhere and maybe a watermark
on some images.
On Thu, Jan 14, 2016 at 4:50 PM, Davide D'Alto
wrote:
> The staging.hibernate.org should now work again,
> It was a pro
WDYM by "recognize the staging website from the production one?" Are
you looking for something else than the different URLs?
2016-01-14 17:53 GMT+01:00 Davide D'Alto :
> By the way, is there a way to recognize the staging website from the
> production one?
>
> If not we should probably add a time
> you looking for something else than the different URLs?
Yes, something different than the URL.
On Thu, Jan 14, 2016 at 5:36 PM, Gunnar Morling
wrote:
> WDYM by "recognize the staging website from the production one?" Are
> you looking for something else than the different URLs?
>
>
> 2016-01
Ok, what for?
2016-01-14 18:45 GMT+01:00 Davide D'Alto :
>> you looking for something else than the different URLs?
>
> Yes, something different than the URL.
>
>
> On Thu, Jan 14, 2016 at 5:36 PM, Gunnar Morling
> wrote:
>>
>> WDYM by "recognize the staging website from the production one?" Are
> Ok, what for?
Right, not so useful in the end.
The idea is to make
make sure that one is publishing the right branch/rake[profile] in the
right url when the site is generated.
On Thu, Jan 14, 2016 at 5:47 PM, Gunnar Morling
wrote:
> Ok, what for?
>
> 2016-01-14 18:45 GMT+01:00 Davide D'Alto
On 14 January 2016 at 15:16, Petar Tahchiev wrote:
> Hi all,
>
> I don't think it's a travesty - I actually use ehcache 2.x now :)
> Thanks Sanne - I'll research infinispan more. One other thing - I see
> there's a module hibernate-infinispan here:
>
> http://repo1.maven.org/maven2/org/hibernate/h
Just to bring everyone up-to-date, the following were fixed in Hibernate
ORM 5.0.7:
* HHH-10421: "native" ID generator for Oracle12cDialect changed to
SequenceStyleGenerator; this change make the "native" ID generator for
Oracle12cDialect consistent with earlier Oracle dialects;
* HHH-10422: fix id
28 matches
Mail list logo
