My question is this. I am using OBIEE 12c and recently I changed the .rpd file in offline mode and then uploaded it to the server. However I dont see my changes there.
Interesting is the fact that when I open the .rpd in online mode in Admin tool, which shows the current rpd in OBIEE, I see my changes. I tried editing in online or offline modes, changed the names of rpds, restarted the server, but nothing helped. What could be the reason?
EDIT.. It was my fault partially. I was making changes in BMM layer and I was pretty sure that my changes will be automatically updated in Presentation layer(it was when I checked with several aggregations), however in this case, my changes did not reflected in Presentation layer. Why is like this?
P.S. I was modifying hierarchies if important
Related
When the TFS server is down and developers work offline, when the server comes back up will it be business as usual even though they made local changes?
Will it just be a pending change at that point?
When you go offline you can carry on working on your files. When you go back online it will check to see if anyone has checked in/out the files that you have been working on.
If none of them have changed, it will check them out for you and you carry on as normal.
If someone has checked in/out then you will have to attempt to merge the files either at that point or on check-in. Sometimes this will auto-merge, others you'll have to do it yourself.
How big a problem this is depends on how many overlapping files are going to be edited. Merging can be a pain, so I'd try to keep that server offline for a short time if possible. If you're using them, avoid changing auto-generated content, such as a Linq2Sql .dbml file as these can be a nightmare to merge.
Thinking about using Team Foundation Server with VS2012 or VS2013. Does TFS track every single local change? For example. If I save a file 10 times locally even though I don't check in, will every one of those local saves be checked in on the TFS server so anyone on the team can see? Of does it just send to the server the latest saved version of the file when you check in? I'm not looking for it to do this because it wouldn't seem to make sense unless a manager wanted to track your hours or something.
MSDN describes the checkin process over here. It is stated there, that...
... all the included file changes from your workspace along with the comment, check-in notes, and links to related work items are stored on the server as a single changeset on your server.
That means that only the last version of your changes made locally will make it into the changeset, onto the server and to your coworkers. You can save as often as you want beforehand, the server won't notice.
Short answer: No.
Longer answer:
I can't think of any SCM that works that way.
Here's how it works, with pretty much any version control system (the terminology will differ from SCM to SCM, but the concepts are the same):
You start modifying a file.
You change the file as much as you want. When you're done, you commit it/check it in.
The contents of the file at that point in time are what's stored in the SCM. No intervening changes are stored.
Recently switched jobs and with it switched source control from TFS to SVN, which is new to me.
In TFS there was an option to disable automatic checkout of files when you started typing in them. It's enabled by default and a lot of users like this behaviour, but I prefer to know for certain what's being changed before committing. A personal thing.
VisualSVN auto-checkouts by default. Is there an similar option to turn it off? I can't seem to find out in the settings.
"Automatic checkout" term in SVN and in TFS worlds has different meanings, as far as I see.
In Subversion, checkout relates to svn checkout operation which gets a working copy from a repository. In TFS it looks like the term somehow relates to automatic locking mechanism.
If you want a file to be locked automatically when you start modifying it in Visual Studio (with VisualSVN extension installed), see the KB article "Lock-Modify-Unlock Model with VisualSVN". I also suggest reading the SVNBook chapter "Locking".
Generally speaking, you can set svn:needs-lock property on files. The property instructs client which files must be locked before editing. After applying svn:need-lock to a file the file gets read-only attribute. Before editing the file must be explicitly locked by the user. After committing the lock is released by default.
Short answer: I don;t think you can do this without becoming very unpopular.
I think you should read up on the SVN redbook's description of how SVN works, especially the versioning models
In your environment, everyone wants to be able to modify any file locally and then send their changes to the server, merging changes with colleague's changes if necessary. This approach works well if 2 people are not changing the same files all the time, which is typical of most dev shops.
The old TFS/VSS model of checkout a file to work on it is pretty obsolete today - the more 'optimistic' approach where you assume you have exclusive access is much more productive. (as usual its easier to ask forgiveness if it goes wrong than ask permission every time)
Your main problem is that you cannot mix these models - if your colleagues are using the merge model, then you have to as well. You cannot lock a file and expect them to still be able to change any file anytime.
Now, there are tricks you can use to prevent yourself from modifying files you never meant to - I'm not sure of VisualSVN but TortoiseSVN (awesome tool) can run client hooks - ie you can write a program to run on every checkout, and that program can be as simple as setting every file's read-only flag. Whether this is god enough for you is another matter.
Personally, I would get used to the idea of change whatever you like whenever. If you accidentally edit a file, you can see the change indicator (AnkhSVN turns the file icon orange for changed files), and its easy to 'svn revert' changes you didn't want to make. Also SVN lets you see diffs really easily, especially on commit - double click the files in the commit dialog. The productivity gains from being able to work without the tools getting in your way (as I found with TFS continually pinging at me as I tried to edit a file) are huge. The SVN tools are really good to let you "ask forgiveness" so you don't need to run in the crappy old TFS way now you've upgraded to something better.
The other advantage is that this applies to files that are not in a Visual Studio project, if you've ever had a project file that was edited outside VS (eg a generated WCF client stub) then you will appreciate how SVN works - never again will you do a full commit and find that TFS has conveniently decided that your changed file wasn't changed and so didn't need to be committed!
Our production Liferay instance absolutely refuses to deploy my latest theme. Something is preventing it from displaying my latest CSS changes. Unfortunately, there are NO log errors and no Firebug Console errors, so it's been a real headache to diagnose. I just get a really ugly plain page with links and no styles applied.
I have tried everything I can think of to fix this.
Undeploy/redeploy theme
restart the Glassfish container
use Liferay Server Administration page to "Clear content cached across this JVM", "Clear database cache", "Verify Database plugins", etc.
undeploy, restart, redeploy
undeploy, delete leftover files/folders pertaining to the theme in 'applications' folder, restart container, redeploy
clear my browser cache
try a different browser
many more combinations of the above. You get the idea.
Last night I reached the boiling point because my theme deployed and displayed in our test environments without issue, but didn't work in production. The only thing that was different is that I wasn't using
include-and-override=portal-developer.properties
in my portal-ext.properties file.
I took a gamble and added this line to my production portal-ext.properties and restarted the production server. My theme now displays without a problem.
The file portal-developer.properties only appears to contain the following properties:
theme.css.fast.load=false
theme.images.fast.load=false
javascript.fast.load=true
javascript.log.enabled=false
layout.template.cache.enabled=false
browser.launcher.url=
combo.check.timestamp=true
freemarker.engine.cache.storage=soft:1
freemarker.engine.modification.check.interval=0
openoffice.cache.enabled=false
velocity.engine.resource.manager.cache.enabled=false
com.liferay.portal.servlet.filters.cache.CacheFilter=false
com.liferay.portal.servlet.filters.etag.ETagFilter=false
com.liferay.portal.servlet.filters.header.HeaderFilter=false
com.liferay.portal.servlet.filters.themepreview.ThemePreviewFilter=true
So, finally, my question is, am I merely trading a slight performance boost for a massively easier deployment experience?
Or are there more serious concerns to loading this file in a production environment?
Thanks in advance for the input!
Ben
You'll get a really bad performance with that portal-ext.properties. That configuration is only intended to be used in development environments.
If you delete the css/.sass_cache directory on your deployed theme you'll see your css changes and you'll be able to use a different portal-ext.properties on production environment.
http://issues.liferay.com/browse/LPS-26939
Regards
This is related to my problem here:
Editing velocity template of Liferay changes not showing or takes a while
I've tried to investigate the caching problem and tried different things. Here's what I found out.
I just found out that my css is also delayed in showing the updates. I tweak my css file adding comment and testing it on my browser. Now just requesting it on the URL it will just give me an older version of the file. now if i put a query asking for version, (eg. mystyle.css?v2) it will pull the latest file and it records it. I can even see different version, eg. (mystyle.css?v1) or (mystyle.css?v2. I've cleaned my cache so it's definitely on the server side (i think).
Is there a way I can clear my cache?
Thank You!
you can activate Liferay's developer setting by including the properties that are in ROOT/WEB-INF/classes/portal-developer.properties.
Explanation: Liferay minifies and caches CSS and Javascript - once this is done it will not examine those for changes. The developer settings will disable that.
However, you don't want this setting active in production as this will mean that you'll have to load dozens of files instead of very few combined+minified, well cached, files.
I assume you are using this for development, not in production.
If you're having these problems in production, you should rather work with a proper theme plugin and redeploy that.