We are using Pentaho Report Designer (PRD) to build out some PDFs and Excel files to the customer. Does anyone have a good strategy for doing version control on these reports? The prpt files seem to be a zipped set of xml. Is there a better format so we can tell what changed from one commit to another?
It is a pain. That's the only format.
You can get pre to work with unzipped archives I believe. But the only way you're going to get nice version control is to unzip before you commit. And re zip on checkout or update.
When I inquire that from Pentaho support for my purposes they said such feature is not there to maintain the version of PRD reports. Then they raised a JIRA request as a new feature.
JIRA ticket
In your commit comment, plainly state what was changed. You won't be able to do a diff on it to see the changes, but by looking at the commits on it you can see what was changed, who made the change, and when.
Related
Many papers are archived in Arxiv.org. A lot of them might also have version histories. But it seems we can't get the update information for one paper when it is updated. Does github support the version history for pdf files? Maybe github can provide the version control for Arxiv.org.
Does GitHub support the version history for pdf files?
Not directly, in that it cannot display diff.
You would need an external diff like diffpdf for that.
Maybe github can provide the version control for Arxiv.org.
Right now, GitHub is not used by Arxiv.org. Their "new" page mentions in 2008:
We have implemented version control for papers submitted prior to November 1997 in the same way as for papers submitted later.
In 2011:
Bulk data available on Amazon S3: The bulk data available for download from Amazon S3 has been extended to include both PDF and source files of the latest versions of all arXiv articles.
I'm using Perforce version control system (http://www.perforce.com/) and would like to format source code files (mainly XML) when developers submit their files to Perforce. I know that Git and SVN allow script hooks that provide for that.
Is there a way to change files that are being submitted to Perforce using some kind of a hook?
How can I do that on Perforce?
Thanks!
When I've done these sorts of policy-enforcement tools in the past, I've done it post-commit.
That is, after the submit completes, my tool retrieves the newly-submitted files, re-formats them according to the policy that I'm enforcing, and submits the re-formatted files as a follow-on change.
I do this by writing a tool that monitors changes similarly to the way the change review daemon monitors changes, so that the tool notices new submits and reviews the new files to see if they comply to the organization policy.
I generally have the tool perform a "revert -a" prior to the submit, so that if the files were formatted according to policy by the original developer, no second submission occurs.
I actually think this is a better approach than trying to do it during the submit:
The change that is submitted is exactly as the user provided it, with the identical content as provided by the user
The modifications that are due to the tool are clearly visible in a separate submission, which makes it very easy to recognize when the tool has gone astray and damaged the file during its re-formatting (such tool bugs do occur).
The net effect, overall, is the desired one: the files at the head of the branch are formatted according to company policy.
A Perforce trigger is what you need.
My team is currently in the situation that half the team is in Germany and the other half in the Netherlands.
We're using Mercurial as source control. The problem is that now that we are split up, because the way the company network works, it is not possible to connect our repositories together to do any pushing or pulling between them.
I was wondering if it is possible to somehow export a bunch of changesets, send it by mail or w/e and then import them on the other side?
I'm really new to Mercurial and distributed source control (previously I only worked with SVN really). But I understand that one of the differences is that it merges by reapplying all the changes instead of just looking at the difference between latest versions. That's why I thought that this might be possible.
Thanks in advance.
Yes, you can do this. See http://www.selenic.com/mercurial/hg.1.html#email
Edit: Use -b/--bundle to send multiple changesets as a bundle.
I have looked for the 'patch' system but I don't think this is what I want. I've also done a little research but I am not sure how I should ask the question.
I want to make a package with only the modified files of the latest revisions on Github.
I am wondering if there's a little application or some sort of commands I could use instead of going into each revisions and track files by files which have been modified to then pack them all into a zip/tar.gz file.
Reason we want to do this is obviously update a lot of websites using an older version, without having the trouble to go look up for each files that we're modified and pack them 'by hand'
Thanks.
Perhaps this might help? Exporting / Archiving changed files only in Git
Looks like a similar issue if I understand what you are trying to do!
I am going to use p42svn for the first time and I have some doubts/questions regarding the same.
As I understand from the p42svn home page, the script p42svn.pl should be run from the machine that hosts the Perforce repository. This script generates an SVN readable dump file which can then be imported into SVN repository. Could you please confirm if my understanding is correct?
In our scenario, we do not want to have all the revisions of the files. We would only need the revisions for the past 1 year. Is it possible to achieve the same?
Instead of migrating all the projects from the Perforce Depot in one go, is it possible to migrate the Projects one by one?
Any help in this regard is highly appreciated.
I've never used the script myself, but reading the documentation leads me to:
yes.
Use the --changes switch. Find the relevant changes
with p4 changes -s submitted #2010/11/17,#now (that would give
you the changes starting a year ago, adjust to your needs)
My SVN knowledge is not good enough for this to comment on, but maybe the
answer to this question helps?