If two people are working on the same EAP file and later want to merge it. Can they do it?
Is it possible to merge two EAP files?
My original, accepted answer: (also note the 2018 update below)
Have a look at this manual section:
http://www.sparxsystems.com/enterprise_architect_user_guide/projects_and_teams/teamdevelopment.html
As with all collaboration, there is a chance for raising conflicts when more that one person works on the same data.
From EA's side the most straightforward approach is the XMI transfer (import/export).
If you collaborate on a regular basis you might want to setup more advanced version control. (see above weblink) Careful, the feature availability depends on the EA version that you use.
As pointed out here it is possible for small teams to access and work on the exact same file on the FS.
Update from 2018:
The user guide has been updated and is available through new URLs. The current user guide page now differentiates methods for
network deployment of EA files
Replication (including a sub-page that also deals with resolving merge conflicts)
XMI Export / Import
In the meanwhile there is a 3rd party solution of LieberLieber avbailable, the Model Versioner, with which you can diff and merge EAP files on the model level:
https://lemontree.lieberlieber.com
Related
I am researching development in VisualFiles.
How can I use version control on the files(scripts) I have changed?
My solution so far:
Setup:
Create a folder structure within the repository according to my applications.
Update process
I will modify a file in visual files
I will then manually have to update file in a repository
Commit the changes against a work item
Is there a better way of introducing version control for VisualFiles. Because to me this feels like not an ideal solution
Thats pretty much the only solution at the moment. The team I am in does something similar but only really for major versions, in minor changes we will feature-switch within the code and leave the old edits inline with dates and initials
The platform provider (LexisNexis) have determined changess to code editor functionality as "likely to implement". This may or may not include version control, that is not yet known, if it does it will be in released v4.1+. There are no other tools available to achieve your aim within the platform. Ask your account manager for access to the ideas portal and you can see when their dev team commit to enhancements such as this.
As source/version control is a long standing issue, any devs using the platform have always had to find workarounds as per your suggestion. The providers are highly unlikely to push any version control functionality with backwards compatability pre v4.
I am using mercurial via tortoiseHg (windows) as a source control management tool.
I am used to merge using beyond a compare. Today, I have to perform a very complex merge and I just discovered a new feature (my client was updated some days ago) that is extremely annoying.
When I have a conflit and ask Mercurial to take the "other" file and keep the original in a .orig file, the .orig is added with <<<<<<< local and >>>>>>> other, but more than this, the other part is merged into the original one !!!
The two parts are then unaligned and it's impossible to guarantee that the merge is OK because you have to review it line by line with no help from the comparision tool. (see screen below).
http://s13.postimg.org/yor6gno47/Untitled.jpg
I want to disable this feature, but so far, I am unable to do it. Thanks so much for help as this is furthermore blocking my work.
Regards.
The launching of a specific merge tool isn't something Mercurial controls. It does, however, have a robust mechanism for Merge Tool Configuration that allows you to provide a preference order and it will use the first one it can find. The builders of various Mercurial installation packages (ubuntu, etc.) and tools that include Mercurial (TortoiseHG, etc.) all provide their own Merge tool configuration preference list.
Either the old merge tool configuration list you had not longer points to Beyond Compare at the right location (upgraded BC and the directory name changed, etc.) or you got a new merge tool configuration list when you updated some software that included mercurial. Either way that page on MergeToolConfiguration will help you find your preference list in your hgrc files and update or correct it.
Tl;Dr: this isn't a "new" feature it's your new installation being less tailored for your system than your old one. Maybe find who packaged that one and copy the merge tool config.
I have been reading about version control in enterprise architect. Here is a small scenario that I have. Can anyone please tell me how enterprise architect behaves in such a situation.
Suppose the package is being shared by 3 users and the package has a number of classes each having some activity diagrams and state machines.
Incase a user A makes any changes to one of the state machines and commits his changes.
Will these changes be reflected in the diagrams of the other users as well if the user updates his copy.
Thank you guys
Of course, it supposed to behave like this.
Why don't you try it?
Create a repository and local copy of version control.
Then from EA add packages to the version control and start testing.
Wonderfull material about EA with version control can be found here :
Best Practices
Implementation in EA is described clearly here
Creating SVN repository can be done easily with visual svn
Creating local copies of svn can be done with Tortoise svn
Good luck!
We have a legal requirement to ensure the latest version of documents (mainly Word and Excel) are readily accessible. We currently implement document control by manually updating the page footer with a new version number but want a better system.
I've played around with TortoiseSVN and the functionality is good; but the problem is that unless I've missed a configuration variable somewhere, Subversion applies version numbers to the whole project (i.e. every file in the repository), not to the individual files. What I want is to be able to create a folder in the repository and all our documents go in there, and the version numbers of the files are only changed when that particular document is changed. Currently if we had 30 files and each was printed and put on display including the version numbers, if someone went to the repository the version number would almost certainly have changed even if the document contents were identical. Not ideal.
The alternative to this would be to create a new repository for each and every document but the administrative overhead on that will be prohibitive. I'm essentially looking for something that does much of what TortoiseSVN does, but treats files as individual projects with their own independent version number.
Whatever solution we come up with we would want the version of the document to be automatically shown in the page footer of the document. Tortoise can do this with a macro http://insights.oetiker.ch/windows/SvnProperties4MSOffice/.
Appreciate any help, thanks.
Greg
I think what you're actually looking for is a document management system.
Version Control Systems (VCS), such as Subversion (the underlying technology behind TortoiseSVN), are fundamentally unsuited for your task due to their focus on tracking changesets among all files within a given project (i.e. one changeset/version can involve changes to many files within the project).
Another advantage of using a document management system is that they typically allow you to attach extensible metadata attributes to your documents in a much richer way than version control systems, as well as providing search capabilities.
There are a few mercurial extensions for dealing with large binary files.
Bfiles
BigFiles
Snap
kbfiles
others?
I'd like to use the one that is most likely to be official (ie distributed with mercurial).
Kiln 2.0 uses a fork of Bfiles for its binary files. Does that make it more likely to become official?
Which is the preferred (semi-official) extension for handling binary files?
It appears that Mercurial is planning to incorporate the 'largefiles' extension for the November 2.0 release. Mercurial incorporated the 'largefiles' extension in the 2.0 release. This extension is a descendent of 'kbfiles' (from Kiln), which is in turn a descendent of the bfiles extension.
It makes largefile support much more integrated into the Mercurial commands than bfiles did, and supports pushing to http(s) urls which I believe bfiles did not.
Kiln repo
preparation work on mercurial-devel
release expectations
It's too early to tell. And it is way too early to start talking about including any of these extensions with Mercurial. IMHO they should all be considered experimental.
(I'm the author of one of those extensions (bfiles), so this is as authoritative an answer as you are likely to get. If someone proposed shipping any one of these extensions with Mercurial today, including mine, I would be strenuously opposed.)
Also, there is no logical link between game development and which extension to choose. It doesn't matter if you're tracking movies, game data, jar files, medical imaging data, or what: most source-control systems are not very good at handling it, and there is no clear answer yet which is the right way to do it with Mercurial.
IMHO stackoverflow is really not the right place for this sort of discussion; the mercurial-devel list is.
It seems that BigFiles is recommanded by game developpers using Mercurial, so maybe you should go with it. However if you want to know wich one is worked to be included in a coming version of mercurial, you should ask in or read the developers' mailing list.
Errr... Nexus. Or any other artifact repositories (or any other backup systems if you only need the latest version).
Because no binary file (especially large one) really belong to a VCS where you would want to diff or merge.
Sure, you could use a VCS, and there are actually good arguments for it, but a VCS is simply not designed for that at its core.