If there are 55 versions of a file in any configuration management system and then a developer checked out the 50th version...edit it and then check in again...what will be the new version of the file ?
Will it be 56th ?
or a new version would be 51th...and existing versions will be incremented by one.
Surely not the 51th, changes are incremental in time, not in content.
To have a clear history of the changes, there will be be a 56th version for reverting changes that occured between the 51 and 55, in order to make it clear that he's going back. Then anothor version, the 57th for the changes he actually makes.
Should be version 56, and file merge would happen when checking in the file if there is any conflick between v55 and the new version.
Another good way to manage the versions is to branch out the historic version (v50). After you modify the files (like adding features, fixing bugs, etc.), you can merge it back to the original.
Related
I have two .mdb files with one being a copy of the other. When there are made changes to the original mdb i want to merge them into my copy, which itself may have changed meanwhile.
As I require to use access 2002 Version Theres a lack of helpful plugins but Id be fine with Just using SaveAsText and LoadFromText Methods.
The Problem is - when i change the file i generated with SaveAsText, the checksum at the top of the file does Not Match the Content anymore and Access throws an Error 3011 when I Try to do LoadFromText.
Does anyone know about a way to work around this issue?
When I go to check something into MorphX VCS right now, I get the following message:
Cannot create a record in SysVersionControlMorphXRevisionTable (SysVersionControlMorphXRevisionTable).
The record already exists.
With things that have already been checked out once, I've been able to resolve this with a get latest and then a new checkout/check in. However, when it comes to doing an Add, I'm completely stuck. Is there a resolution to this or have we completely borked our VCS?
Note: this error is only given when we try to check in from a development project. Checking in directly on the AOT does not give this issue.
Just look at the table SysVersionControlMorphXRevisionTable (in SQL if you can't access) and see what the duplicate record could be. The unique index is ItemPath and Version. I doubt you'll see anything here though.
It's most likely an issue with the call in this method \Data Dictionary\Tables\SysVersionControlMorphXRevisionTable\Methods\latestVersionNumber where it's trying to get the current highest revision and is being called by \Data Dictionary\Tables\SysVersionControlMorphXRevisionTable\Methods\create.
Put a breakpoint in the create method line #48 and see what revision.Version is, and before the insert, check in SQL if the ItemPath/Version already exists in SQL.
I'd guess it's probably a server/client-caching issue. To resolve, refresh all of your client caches under Tools>Caches. If this doesn't resolve, and it's a good idea to do anyway, copy these menu items:
\Menu Items\Action\SysFlushAOD
\Menu Items\Action\SysFlushData
\Menu Items\Action\SysFlushDictionary
\Menu Items\Action\SysFlushReportServer
To a new menu item and change the property RunOn = Server. Then run these and it'll flush your server caches. If this still doesn't work, try restarting the AOS.
If this doesn't work, your users application user cache files might be corrupt. Close your client and delete the *.auc and *.kti files in %LocalAppData% folder (Typically C:\Users\[user]\AppData\Local) and reopen your client.
In the environment you are using, have you restored a copy of another database somewhat recently?
Edit: Now knowing that you did a DB restore, there is a good chance your GLOBALGUID was reused and/or is causing caching issues. See here for more info about how/why this happens.
You should probably stop your AOS and run these SQL commands:
UPDATE SYSSQMSETTINGS SET GLOBALGUID = '00000000-0000-0000-0000-000000000000'
DELETE FROM SYSCLIENTSESSIONS
DELETE FROM SYSSERVERSESSIONS
Are/were you also having issues with batches running? (Somewhat related, but I'm mainly just curious on this question)
Currently the plugin will generate a series of files in an IProject, I need to check whether the generated file has been modified by user before. If the generated artifact has been modified by user, I will need to handle the regeneration differently.
What I can think of is by checking Creation Date == Modified Date . The fact that I will delete the old file and create it again when user has not touched the file before to make sure the Creation Date always equals Modified Date. However I did not see how to retrieve these 2 properties from IFile. Anyone can help me regarding this?
I am quite new to Eclipse plugin development, can anyone suggest another way around this ?
*** Generated files cannot be locked as those are source codes
The modification stamp of an IFile or more generally an IResource can be obtained with getModificationStamp(). The return value is not strictly a time stamp but should serve your needs, see the JavaDoc for details.
If, however, you would like to track whether the content of a file was changed I would rather compute a hash of the content, for example with a MessageDigest. You can then compare the two hashes to decide whether the file was changed.
This latter approach would regard a file as unchanged if it was changed - saved - changes reverted - saved again. The modification stamp on the other hand would declare the file as changed even though its content is the same again.
Whichever approach you choose, you can store the modification stamp (or content hash) at generation time by using IResource#setPersistentProperty() and later compare it with the current modification stamp. Persistent properties are stored on disk with the platform metadata and maintained across platform shutdown and restart.
I found the answer:
private boolean isModified(IFile existingFile) throws CoreException {
IFileState[] history = existingFile.getHistory(NullProgessMonitor);
return history.length > 0;
}
This feature is maintained by eclipse IDE so it will survive the restarting of eclipse. If the file has been created without modification , the history state is zero.
You can clear local history by doing:
existingFile.clearHistory(NullProgessMonitor);
Trying to reduce the size of my (DB synced) workspace - realized that the folder
${workspace_loc}\.metadata\.plugins\org.eclipse.jdt.core
was taking ~35 Mbytes - the contents of the folder are .index files (which take the most space) and some others (which are a couple Kb worth) :
[0-9]*\.index
externalLibsTimeStamps
indexNamesMap.txt
invalidArchivesCache
javaLikeNames.txt
nonChainingJarsCache
participantsIndexNames.txt
savedIndexNames.txt
variablesAndContainers.dat
I can't seem to be able to find docs on those. Can I safely delete them ? Can you point me to some docs on the JDT plugin folders/files contained in ${workspace_location}\.metadata\ directory ?
Is there any way via the gui to clean up the caches (preferably periodically) ?
PS : I 'm on Kepler if this makes a difference
PS2 : links to docs may be links to code comments and such
Yes, you can safely delete them, but it is not very useful.
According to an answer to How would you access Eclipse JDT index?, these files are the class index used when you "Open Type..." (in Refactor>Open Type... or via Ctrl+Shift+T). So if you delete them, next time you want to open a class using "Open Type..." the classes will be reindexed.
Therefore, deleting it for the sake of saving space has little sense, as it will be re-created. Deleting is however useful if you think you have something messed up in your index, it is a way to update it, as the refered answer suggests.
Generally,our fixes/patches for any bugs involves changes in multiple files and we will commit all these files in a single shot.
In SVN, for each commit (may involve multiple files),it will increment revision number of whole repository by one. So, we can easily link all the multiple files that went in a single commit.
Now the difficulty with the same case in CVS is that it will increment the revision numbers of all the files individually. Let's say if a commit involves the following files:
file1.c //revision assigned as part of this commit..1.5.10.2
file2.c //revision assigned as part of this commit..1.41.10.1
and the comment given for this commit is "First Bug Fix".
Now, the only way to get all files checked-in as part of this commit is by searching through all the cvs logs for comment "First Bug Fix" and hopefully it will return only the two file revisions mentioned above.
Please share your views on if there is any better way in CVS to keep track of all files checked-in in a single commit instead of relaying on comment given as part of commit.
I think CVSps might do what you are looking for.
"CVSps is a program for generating 'patchset' information from a CVS repository. A patchset in this case is defined as a set of changes made to a collection of files, and all committed at the same time (using a single 'cvs commit' command). This information is valuable to seeing the big picture of the evolution of a cvs project. While cvs tracks revision information, it is often difficult to see what changes were committed 'atomically' to the repository."
This cvsps relies on cvs client. Make sure you have proper version of cvs which supports rlog command (1.1.1)
CVS does not have inherent support for "transactions".
You need some additional glue to do this. Fortunately, this has all been done for you and is available in a very nice extension called "cvszilla".
The home page is here:
http://www.nyetwork.org/wiki/CVSZilla
This also ties in to CVSweb, which is a great way to browse through your CVS modules via a web-based GUI.
Perhaps the ANT CvsChangeLog Task is another choice. See http://ant.apache.org/manual/Tasks/changelog.html . It provides date and time for a checkin message. You can produce nice reports with XSLT - try the example at the bottom of the ANT manual page.
I know it's late for an answer, but perhaps other users come across this like I did (searching) and appreciate the ANT integration.
OK, I just installed cvsps and ran it from the top level. Here's a sample of the output... this is one of the few hundred patch sets on my module. Note that indeed this does work across different directory trees.
---------------------
PatchSet 221
Date: 2009/04/22 22:09:37
Author: jlove-ext
Branch: HEAD
Tag: LCA_v1_0_0_0_v6
Log:
Bug: 45562
Check the length of strings in messages. Namely:
* Logical server IDs cannot be more than 18 characters (forcing a
TCSE protocol requirement).
* Overall 'sid' (filter) search string length cannot be more than
500 (this is actually more than the technical maximum messages are
allowed, but is close).
Alarm messages and are now not going to crash either as the alarm text
is shortened if necessary by the LCA.
Members:
catalogue/extractCmnAlarms.pl:1.2->1.3
programs/ldapControlAgent/LcaCommon.h:1.18->1.19
programs/ldapControlAgent/LcaUtils.cc:1.20->1.21
programs/ldapControlAgent/LcaUtils.h:1.6->1.7
programs/ldapControlAgent/LdapSession.cc:1.61->1.62
tests/cts-45562.txt:INITIAL->1.1
So, this may indeed do what you want. Nice one, Joakim. However, as mentioned, CVSzilla does much more than this:
Web-browsable CVS repositories (via CVSweb).
Web-browsable transactions.
Supports transactions across modules.
Generates CVS commands (using 'cvs -j') to merge patchsets onto other branches.
Integration with bugzilla (transactions are automatically registered against bugs).
If all you want is just the patchset info, go with cvsps. If you're looking to use CVS on large projects over a long period of time and are thinking about using bugzilla for your bug-tracking, then I would suggest looking into CVSzilla.
This also could be useful:
http://code.google.com/a/eclipselabs.org/p/changelog/