Hello Alex!

A big help would be :

In every file whereever there are areas that are revised gets an official commenting line like

# revision 1.01 start

... code...

# revision 1.01 finish

With this system we know that only that particular areas needs to be revised to any file. Also a readme file will tell which are the files that have been revised and the importance. Not just bug fixes. This helps to build up a system from the begining with all the links SQL users to have a custom modifications going on and also to keep pace with the revisions. Moreover this way of commenting gives a system where all the line numbers are given by you officially and can also then be refered at a later date in case of problem. So everyone knows which line one is talking about.

It could be only a simple revision of a line or even a set of lines of perl codes. Later in use all the users can erase the codes for the final use, if they want or wanna bring down the bytes of their cgi.

Otherwise atleast it can be a good mess for people who wants to customize their cgis which is what you do not wish your users to end up with such disappointments.

------------------
rajani

so if he were to have revised every two lines.. then it would make the script 3 times longer

well since he is getting paid like $400 from each one of you.. i guess that's fair..

GOOD LUCK ALEX

jerry

That's what tools like diff are for. You can compare 1.02 and the new version and instantly see what files have changed and at what spots. No need to add in all those comments. =)

Cheers,

Alex

Alex!

Your suggestion is not something that is new and unknown, thankyou. But whats wrong in saving our time regarding that part so that one does not have look with big eyes everywhere.

Not to increase the line numbers one could also do the following :

New code..........# Revision 1.01 begin
New code..........# Revision 1.01 end

This would be in the same line!!! Therefore there will be no new line occuring than official lines of the scripts.

Most of the cgi`s are full of comments. Thats is to help users to understand and save their time. Those principles have something worth in them. Nor it does take more time in inserting the comment. But all the Links SQL users will save atleast half an hour per user in comparing the code.

rajani,

Any text editor worth its salt has a file compare function that will point out the differences in any two files lickity split. It's the easiest way to find out where the changes are whether you like it or not.

What you're asking Alex to do is ridiculous, a huge waste of time, and would seriously bloat the size of the files.

If you think everyone else is so wrong (again), why don't you go ask your programmer friend that you used to talk so much about?

Here's a good text editor:
http://www.ultraedit.com/

Brent

Hello Alex!

I find it too difficult to find out everywhere the changes.

If atleast if the sub_routines are given the version numbers that would also be soooo helpful. Tp check every line and every point one may not notice a bug correction. So if the sub_routines gets a new version number than one can change the entire routine.

Anyway, ....



------------------
rajani

Do this:

1. Download CSDiff:

http://www.componentsoftware.com/csdiff/

2. Extract the new version into a new directory.

3. Run CSDiff on your old directory and your new one.

You will then get a list of changed files, and you can then look in a file and see exactly what changed.

Hope this helps,

Alex

Hello!


Yes, I admit..

I was not aware of such a possibility. Hence it was a big question as to how to keep up pace with the upgrades. Hence the question.

However, thankyou to Alex and Brent and hope that it also helps everyone else.

Now I am using both the programs and see that my life have been easier. It has not only helped me for revision comparisions but many many other things. This was a BIG help indeed.

------------------
rajani