I believe I have found a bug in the sqlCVS binary

[jondecker76]

When an qdlCVS diff is run, a status is returned against database entries (Change:NEW, Change:MOD, etc..) Recently, while investigating an unrelated bug, I noticed that I have never seen Change:DEL in sqlCVS. Looking through the source, there indeed should be a Change:DEL status for entries that have been deleted in the local working copy of the database that exist in the master database.

To further test this, I purposely deleted some entries from my local database to test this out..  I chose something that I would likely never need - so I looked at InfraredGroup_Commands for FK_InfraredGroup #5956 (just listed as "qqq").
In InfraredGroup_Commands, I deleted the entry PK_InfraredGroup_Command 166388. Running sqlCVS agains all IR database tables, I was presented with some Change:NEW for a lot of my new additions for my own IR devices, a Change:MOD for one that I had modified, but no Change:DEL!

Any easy way to test this is to do an sqlCVS diff from the web admin. sqlCVS outputs a file to /tmp that is used for generating the web page. If you look in /tmp, the temporary files of the sqlCVS output will be apparent to you. You can see that Change:DEL is nowhere to be found - even though I had just deleted an entry tracked by sqlCVS on my local database copy. (i checked the temp file just in case there was a bug displaying DEL information in the web admin page - but the output on the web admin page matches the sqlCVS generated file.)

I only spent about half an hour on this before coming to work this morning, but wanted to hear if anyone else could reproduce my findings while I'm at work today so I can start digging into why Change:DEL is not being flagged for locally deleted files.

[hari]

just tested on my installation:

Code Select Expand


    Repository                                 New   Mod   Del
  1 dce                                         13     0     2
  2 ir                                           0     1     0

30 DeviceTemplate_DeviceCategory_Controlled     2     0     2


this was a wrong setting in one of my device templates, i've removed it.

Code Select Expand


30
Changes for table: DeviceTemplate_DeviceCategory_ControlledVia
    User     New   Mod   Del
      0      2     0     2
What user do you want more detail on?
Enter 'b' to go back, 'q' to quit
Enter 'a' to show all, 'r' to revert all
a
Changes to table: DeviceTemplate_DeviceCategory_ControlledVia by user: 0
   1 NEW PK_DeviceTemplate_DeviceCategory_ControlledVia=4940
   2 NEW PK_DeviceTemplate_DeviceCategory_ControlledVia=4941
   3 DEL psc_id=1884
   4 DEL psc_id=1885
Enter 'b' to go back, 'q' to quit, 'rX' to revert change X


i ran /usr/pluto/bin/sqlCVS -R 3999 -H sqlcvs.linuxmce.org -r dce,ir diff

best regards,
Hari

[jondecker76]

Thanks hari,

would you mind running:

Code Select Expand


/usr/pluto/bin/sqlCVS -R 3999 -H sqlcvs.linuxmce.org -r dce,ir -e -f ~/sqlCVS_Result.txt diff
/usr/pluto/bin/sqlCVS -R 3999 -H sqlcvs.linuxmce.org -a -n 'dce,ir -e -f ~/sqlCVS_Result2.txt diff


in the resulting file, do you see any DEL references? (the part of sqlCVS which generates the table display for file output is separate from the CLI output)

[hari]

Thanks hari,

would you mind running:

Code Select Expand


/usr/pluto/bin/sqlCVS -R 3999 -H sqlcvs.linuxmce.org -r dce,ir -e -f ~/sqlCVS_Result.txt diff


Code Select Expand


REP:dce TABLE:DeviceTemplate_DeviceCategory_ControlledVia       USER:0  CHANGE:DEL      WHERE: WHERE psc_id=1884
REP:dce TABLE:DeviceTemplate_DeviceCategory_ControlledVia       USER:0  CHANGE:DEL      WHERE: WHERE psc_id=1885


Code Select Expand


/usr/pluto/bin/sqlCVS -R 3999 -H sqlcvs.linuxmce.org -a -n 'dce,ir -e -f ~/sqlCVS_Result2.txt diff


that looks strange.. and is not a valid sqlCVS command :-)

best regards,
Hari

[jondecker76]

thanks again

oops! the 2nd one I didn't mean to have the ' in there before the repositories.. Anyways, you are getting Change:Del, so when I get home I have to do a little experimentation to see why web admin does receive it (its looking to me like its in the parameters to sqlCVS)

[hari]

thanks again

oops! the 2nd one I didn't mean to have the ' in there before the repositories.. Anyways, you are getting Change:Del, so when I get home I have to do a little experimentation to see why web admin does receive it (its looking to me like its in the parameters to sqlCVS)

i've alredy tested it without the "'", the arguments are wrong.

best regards,
Hari

btw: the web checkin from the diff page is broken, the checkboxes are not evaluated

[jondecker76]

Hari

Yes, I am aware of the checkin/revert bug where checkboxes are ignored. this is something I'm working on fixing

Whats funny about the invalid sqlCVS line - its exactly what is called by the web admin

[jondecker76]

this is very strange.. I deleted another database entry (from InfraredGroup_Command - PK_InfraredGroup_Command = 781 - on of the EIB commands)

ran sqlCVS manually:
/usr/pluto/bin/sqlCVS -R 3999 -H sqlcvs.linuxmce.org -a -e -r dce,ir diff

and I still can't get it to show anything as DEL. I even tried directly passing the table with -t InfraredGroup_Command.. still no go...


can anyone else confirm this? I don't get why it would be just me...  Check your sqlCVS diff output, remove something from InfraredGroup_Command, then run a sqlCVS diff again.  its not flagging that one of the InfraredGroup_Commands has been deleted

[hari]

can anyone else confirm this? I don't get why it would be just me...  Check your sqlCVS diff output, remove something from InfraredGroup_Command, then run a sqlCVS diff again.  its not flagging that one of the InfraredGroup_Commands has been deleted

there is some other ir code sharing feature in lmce, maybe that is related?

best regards,
Hari

[jondecker76]

ok thanks, i will follow up on that. I thought that IR codes were handled through sqlCVS also

[jondecker76]

I spent all night on this and finally have it figured out. It just happened that I was deleting entries that didn't have a psc_id assigned - thus no sqlCVS tracking..

The really really good news is that I have a very good understanding of sqlCVS now after digging through the code. Once i had a full understanding, the bugs in the sqlCVS web admin immediately jumped out at me when I was glancing at the source .php files this morning before heading off to work. This means I should have the web admin fixed (With some additions such as leaving a comment with commits) in the next couple of days

[PeteK]

The really really good news is that I have a very good understanding of sqlCVS now after digging through the code. Once i had a full understanding, the bugs in the sqlCVS web admin immediately jumped out at me when I was glancing at the source .php files this morning before heading off to work. This means I should have the web admin fixed (With some additions such as leaving a comment with commits) in the next couple of days

That's great news!  I look forward to seeing the fixes.

[hari]

I spent all night on this and finally have it figured out. It just happened that I was deleting entries that didn't have a psc_id assigned - thus no sqlCVS tracking..

The really really good news is that I have a very good understanding of sqlCVS now after digging through the code. Once i had a full understanding, the bugs in the sqlCVS web admin immediately jumped out at me when I was glancing at the source .php files this morning before heading off to work. This means I should have the web admin fixed (With some additions such as leaving a comment with commits) in the next couple of days

you rock :-)