Hi,
we're two people working on the same system. We both have all files (project .app, cobol .cbl, copyfiles .cpy, etc) on our separate pc/drive. Now, the problem is, that the project file's timestamp is updated even when just opening the project. Thus it is impossible to see which project file is the most recent (since the timestamp of one can be newer (because it was opened), even though no changes to the project itself have been made). We're also using SmartGit to help us track the softwares versions, but this tool can only compare text files (like .cbl and .cpy), but naturally not .app-files.
Is there a way to keep the .app-file's timestamp from being updated while only opening the project? Has anybody else had this problem? If yes, how have you solved it?
Thanks in advance for all your help!
Cheers,
Raffi
Let me rephrase the question:
Why does NetExpress 5.1 update a project files (.app) timestamp, even if I just open and close it in NE5.1? Is there a way to turn this off?
Second question:
What tools are other users using for version control? We're using SmartGit/Hg and it turns out the .app-files cannot be handled properly. So we're open for suggestions about other, more useful software to be able to do proper version control.
Regards,
Raffi
Hi,
we're two people working on the same system. We both have all files (project .app, cobol .cbl, copyfiles .cpy, etc) on our separate pc/drive. Now, the problem is, that the project file's timestamp is updated even when just opening the project. Thus it is impossible to see which project file is the most recent (since the timestamp of one can be newer (because it was opened), even though no changes to the project itself have been made). We're also using SmartGit to help us track the softwares versions, but this tool can only compare text files (like .cbl and .cpy), but naturally not .app-files.
Is there a way to keep the .app-file's timestamp from being updated while only opening the project? Has anybody else had this problem? If yes, how have you solved it?
Thanks in advance for all your help!
Cheers,
Raffi
Unfortunately, the Net Express project file is an opaque blob, and as you note it's modified by the IDE every time you open it. (These are not design decisions I personally agree with.)
Since there's no way to automatically determine whether the changes to the .app file are important, you really only have a few choices, none of them ideal:
- Don't keep .app files under version control at all. Obviously this makes them difficult to recover and is unsatisfactory.
- Use a version-control system that requires users to manually commit changes, and have users determine when the .app file has changed in a significant manner (in which case they should commit it) or has not (in which case they should revert it or ignore the changed status). You can do this with any version-control system that doesn't automatically attempt to commit changes: RCS, CVS, Subversion, git (of the plain command-line variety), etc. Clearly this puts more burden on the users.
- Always commit the changed .app file. Handle conflicts either by always accepting the newest version, or by ignoring the conflict and rejecting the change unless the user knows (through some out-of-band mechanism, such as email or a log entry) that a significant change has been made to the file. Again, this makes revision control of the .app file a manual process.
The only real solution I know of, I'm afraid, is to avoid using .app files, which means not using the Net Express IDE. For 5.x and 6.x products, I personally avoid the IDE and use the command-line tools and makefiles, which support versioning properly. With Enterprise Developer, the Eclipse and Visual Studio IDEs use text build files and so also support versioning.
Hi,
we're two people working on the same system. We both have all files (project .app, cobol .cbl, copyfiles .cpy, etc) on our separate pc/drive. Now, the problem is, that the project file's timestamp is updated even when just opening the project. Thus it is impossible to see which project file is the most recent (since the timestamp of one can be newer (because it was opened), even though no changes to the project itself have been made). We're also using SmartGit to help us track the softwares versions, but this tool can only compare text files (like .cbl and .cpy), but naturally not .app-files.
Is there a way to keep the .app-file's timestamp from being updated while only opening the project? Has anybody else had this problem? If yes, how have you solved it?
Thanks in advance for all your help!
Cheers,
Raffi
Thanks, Michael, for the excellent reply! This was just what I was looking for.
I'm almost ready to just do manual version control. We're only two people doing only cobol-stuff, so I don't really see a point in messing around with version control software. But since I'm not the boss, it's not up to me...
I'm also looking into Visual Cobol, but haven't had enough time for that yet.
Thanks again for the reply!
Hi,
we're two people working on the same system. We both have all files (project .app, cobol .cbl, copyfiles .cpy, etc) on our separate pc/drive. Now, the problem is, that the project file's timestamp is updated even when just opening the project. Thus it is impossible to see which project file is the most recent (since the timestamp of one can be newer (because it was opened), even though no changes to the project itself have been made). We're also using SmartGit to help us track the softwares versions, but this tool can only compare text files (like .cbl and .cpy), but naturally not .app-files.
Is there a way to keep the .app-file's timestamp from being updated while only opening the project? Has anybody else had this problem? If yes, how have you solved it?
Thanks in advance for all your help!
Cheers,
Raffi
Oh, I think version control is always worthwhile. I use it on nearly everything I do - including personal documents and other things only I edit.
There are at least four reasons for always using version control:
- It lets you revert changes you decide weren't what you wanted after all.
- It's a backup: it lets you recover from such accidents as deleting the wrong file.
- It's a historical record of the changes you made, when you made them, and why (if you provide decent log messages). Sometimes that's invaluable.
- If it's a distributed revision-control system, it's a convenient way to share individual files among multiple machines and synchronize changes.
I've seen too many cases where a file that only one person is working on gets accidentally deleted, or the developer makes a massive change to the code that turns out to be wrong, or the like. At times I've been the culprit. Version control came to the rescue in all of them. It's saved me more work and frustration than I can tally up.
