In my project I am using mapforce to create XSLT transforms. The problem is that mapforce generates different output even after a minor change (different var names, different object sequence etc.)
If I implement some functionality in, say, Project branch 1.2 and other developer adds another functionality in branch 1.3, and we both submit changes to branches 1.2 and 1.3 respectively, there is no way one can just integrate changes (I am using Perforce for version control) to version 1.3, it has to be reimplemented.
Is there anyway I could overcome this? Maybe a version control plug-in in mapforce?
I'm afraid this is just a limitation of code generators. Most just assign new labels (or numbers) as they go along, so depending on where the added code is, everything generated after that point will be changed.
To fix it, the MapForce code generator would have to save the metadata used when generating code, and re-use it the next time you generate code. The generator would have to distinguish new items from those that have just moved, and re-use all existing ones. It might be a major change to their software to do this, depending on how it is currently implemented.
It can't hurt to request/suggest such a feature, and having it would help Altova position Mapforce as more of a production-ready solution, able to support version control of the customer's work.
Related
I have found myself trying to upgrade Apache Superset from version 0.35 to 0.37 or soon 0.38 as is about to get released.
Our version of superset was heavily modified, from code added to the default superset files to creating new one. We are talking about hundreds of files changed with 1 to 1000+ added lines Given this fact the upgrade fails with a lot of conflicts, something that was expected.
I would like to find a way to make the upgrade to the newest version and keep our modifications as well as making the process easier for future upgrades.
So far (until 0.35) we manage to upgrade to the newest version and solve the conflicts but it became more and more difficult.
The modification were from the front-end jsx files to css to python files.
What I tried and failed:
make a patch file using
diff <0.35 files> <our modified 0.35>
and apply the patch to 0.37 but this did not work as the files are very different between versions and the line numbers changed drastically as well as the folder structure is different in the newer versions.
Is there any way to keep our modification separated and make the process easier for future upgrades?
The more you fork and has the main branch evolves, the harder it gets to upgrade, that is simply to be expected when forking software. Given current high velocity and general pace of change in the Superset code base, and the pre-1.0 status of the software, you can pretty safely assume that any work you do in a fork is likely to be fully revisited every time there's a major upgrade.
The way you prevent that is:
extending only the things that were designed to be extended (plugins, extensions, configuration hooks)
contributing your changes back into the main branch
Many of us have learned that the hard way in our careers. The typical realization is that overtime, the progress in the main branch offer much more value than your customization, and upgrading and applying your customization becomes hard or simply impossible. The usual solution is to look into your customization and identify the really important ones, and try to contribute them back so that they can evolve with the software.
The problem is that the source code distribution is not exactly the code that runs after installation. The installer, which runs when the site is accessed for the first time, generates a lot of code. Also, a running system stores some data in php source code (e.g. user profiles - under the /user_privileges directory) rather than in the database. So, I have the following unsatisfactory possibilities.
(1) Put the original source code under VC and edit it. In this case I have to do a fresh install and run the installer every time to see how my changes are working.
(2) Put the installed source code (after the installer has run) under VC, and edit it. In this case I have immediate feedback, but I can't use that code for new installations. I also have to exclude everything that the running system writes in the source tree from the VC.
Any suggestions?
I am working with Vtiger CRM version 6.0Beta, but any tips relevant to version 5 would help.
Thanks.
Choice 1 is appropriate. VC must always track the source code, not the products of any interpreter or processing. I feel your pain. It is so easy to tweak that Vtiger source code, and VC tends to be left by the wayside.
Get familiar with GIT. Really, it is what you want. Look here, I already did it.
Copy the original code in one branch
Copy the modified code into another branch
Make a diff or better, run git format-patch
Install (checkout) your new Version
Check the patches and apply them, if necessary.
Bonusses
Have a private and a public remote for your repo, so that you can keep track on the crumpy files in user_privileges and friends in private, but share code with others
Have an absolutely beautiful backup with daily rollback by just setting up a branch, a remote and a cronjob.
Beeing able to replicate the live situation within minutes for local development
Painfree Updates !!
I know, this is no easy task, but once done, it will make your live pretty much easier.
So Django 1.5 will be out within an Internet-Week (soon) and I'm feeling the pressure to start playing around with it for its vastly improved User model. But like with 1.4 and 1.3 before it, upgrading is not simply a virtualenv change, I've needed to alter (quite heavily in places) the structure of my projects.
I recently jumped from 1.2 to 1.4 and spend hours (over many projects) updating their file structures (and settings) to mirror modern Django preferences. Django 1.5 is going to force me to go through and fix all the CACHE settings and fix practically every instance of {% url ... %} in my templates.. I'm wondering if there's an easier way.
Is there anything out there that can automagically "upgrade" a Django project?
... Or at the very least "scan" a project to show up the larger honking issues so I can kick those out before starting QC.
No. And for good reason.
Some of the changes between versions are minor (such as the whole quotes around variables thing), while some are major (like the new User model).
While automatic detection might be possible (though non-trivial considering you'd have to execute every possible code path in the app), changing them would be fragile. And possible very dangerous.
Instead, when moving between versions, I move up one version (to the last minor version in for that major) at a time and test. Django will issue warnings for features that will be removed between versions, so it's easy to catch them while still having running code that works.
What is an effective way of maintaining the version of my project?
I started in a project, and I want it to look professional. I want to do a version for my project, like 1.0 or something, but I don't know how to maintain it or from where to start.
Is there a criteria for incrementing the version before the decimal or after the decimal point, I think I read somewhere its major or minor changes.
Also, is there an existing software that works on the version of my project automatically depending on the changes I make on my code?
NOTE: I use Code::Blocks
See this for lots of great information about versioning!
You didn't mention which development platform you were using, but most of them support auto-incrementing version numbers, but this is only good to signify different builds, rather than a whole new version.
Here is an article that describes the basics of version control Source Code Control
What I do is to have a four field version number. This is made up of the following:
Major version number (which seldom changes and only with major changes in functionality)
Minor version number (which sometimes changes with large changes in functionality)
Issue number which (changes with minor changes in functionality)
Build number which is incremented every time I do a build
The purpose of this numbering scheme is so that when there is a field issue, I can determine which version of the source code in my repository was used in the specific build that the field site is having a problem. I can also know what test environment I need to set up so far as files, database, and equipment.
The issue number tends to change when I am making a change in the functionality that may impact database schema in a small way, new parameters being added, new functionality requested for a customer. The Minor version number tends to change when the new functionality or the changes for a customer are significant.
The Major number tends to change only when there is something really earth shattering that means that going from the older major version to the newer major version is a significant upgrade effort. Cases where it has changed was when we moved from Windows CE to Windows XP, an operating system change which required some source changes for that. At the same time we went to UNICODE support for Far East Asian languages as well.
The main thing is to provide some way that when you see the complete version number you can know immediately the major functionality that is there and to know what the version primarily supports and does not support.
When a particular field is incremented, the following fields are reset back to one (1). So when going from Rel 2.2.1 to Rel 2.3.0 the first field stays the same, the second field is incremented, the third field is set to zero, and the fourth field (build number) will start with one for the first build. Then as there is a build of Rel 2.3.0 the fourth field (the build number) will be incremented.
And each time I do a build, I keep the build products (the installers) for that build stored on a server along with the build notes for that build describing the changes made for the build. I also will do a branch in my repository (Subversion) so as to make it easy to find the source code for that build.
in the MFC application I am working on, I need to have an Internet Explorer (we are using the component CHtmlView) displayed, currently we are able to change the rendering mode the IE works in by using the FEATURE_BROWSER_EMULATION registry keys. However that only allows us to change the rendering mode of all the CHtmlView instances in the application, plus to apply that change, we must restart the application.
The problem is, we would like to have more than one version of the IE displayed side-by-side in our application. I know that it is possible to get multiple IE versions on one computer, but I'm not sure, how to get them all in one application.
We have some ideas, how to solve this problem, but they are not really a trivial solutions, so I want to ask for your ideas. Anyway, here is what we've come up with:
Download the source code of the page, add the document compatibility tag, change all the addresses in the document to the absolute ones, and save this page to the disk. Then reload the page from the disc with the IE. This solution works only partially, because although it makes IE to use the correct rendering mode, the page fails to load some of the resources, because it is in the different location than the original - the addresses we had changed works well, but for example the JavaScript generated ones doesn't. And this solution is generally very messy, so we had dropped that.
Use multiple processes - each IE version would have it's own executable/dll library, we use the browser emulation feature on each executable, and then somehow glue this into one application (I admit, I have no idea how, as I've never used multiple processes with windows/MFC). But I don't know, if that solution would even work...
Create a proxy for our application, that will change the downloaded source code in a similar way as the solution 1 presents - it will add the document compatibility tag, to force the IE into the desired mode, but it can leave the addresses intact, as the IE would see the source as coming from the original location. This solution seems to me like the safest one, but like with the 2. solution, I don't know how to make a proxy layer for our application, and more importantly, how much time would it take.
So do you have any ideas on how else could this be solved? If the solution uses something other than CHtmlView, so be it, we can always change that.
As for the IE versions, we would like to have, it would be nice to support IE6, but it is not necessary, the lowest required version is IE7.
Thanks ahead for your time, any ideas would be appreciated.
In the end I have solved this by using
our own proxy server (implemented using boost asio), and modifying the http request/response headers to force IE into the correct compatibility mode.
several executables with unique names, with the compatibility mode set in the registry. Each browser version ran in a separate process.
As it turned out, the proxy server solution didn't always work as expected. The multi-process solution did work as intended, but in the end, the emulated browsers didn't always work as the real browsers, and the whole solution wasn't 100% reliable.
I hope this will help someone in the future.