Author Topic: Flaws of 'Add Comment to Selected Backup'  (Read 2614 times)

jb

  • Community Member
  • Posts: 37
  • Hero Points: 0
Flaws of 'Add Comment to Selected Backup'
« on: April 29, 2009, 08:53:40 am »
The 'Add Comment to Selected Backup' command in the 'Backup History' toolbar basically allows to change the comment of a backup version. The comment is intially empty except when it is "Created by Auto Reload.".
Flaws:
1. The command does not allow to replace a non-empty comment by an empty string.
2. The command automatically trims leading whitespace.
3. The command name is slightly misleading. 'Change Comment of Selected Backup' or 'Edit Comment of Selected Backup' would be more appropriate.

As a consequence of 1 and 2 you cannot delete a comment , but this is needed for example when you commented the wrong backup version.
Also stand-alone version control systems such as SVN allow to delete a log message.

I'm using SlickEdit 14.0.0.7 with hot fix 15.

ScottW, VP of Dev

  • Senior Community Member
  • Posts: 1471
  • Hero Points: 64
Re: Flaws of 'Add Comment to Selected Backup'
« Reply #1 on: April 29, 2009, 03:26:03 pm »
Good feedback. While I agree with 1 and 3, can you elaborate on why 2 is needed?

ScottW, VP of Dev

  • Senior Community Member
  • Posts: 1471
  • Hero Points: 64
Re: Flaws of 'Add Comment to Selected Backup'
« Reply #2 on: April 29, 2009, 03:26:40 pm »
To be clear, why should we not trim whitespace?

jb

  • Community Member
  • Posts: 37
  • Hero Points: 0
Re: Flaws of 'Add Comment to Selected Backup'
« Reply #3 on: April 29, 2009, 11:10:17 pm »
The 'Add Comment to Selected Backup' command in the 'Backup History' toolbar basically allows to change the comment of a backup version. The comment is intially empty except when it is "Created by Auto Reload.".
Flaws:
1. The command does not allow to replace a non-empty comment by an empty string.
2. The command automatically trims leading whitespace.
3. The command name is slightly misleading. 'Change Comment of Selected Backup' or 'Edit Comment of Selected Backup' would be more appropriate.

As a consequence of 1 and 2 you cannot delete a comment , but this is needed for example when you commented the wrong backup version.
Also stand-alone version control systems such as SVN allow to delete a log message.

I'm using SlickEdit 14.0.0.7 with hot fix 15.

To be clear, why should we not trim whitespace?

In the first place I mentioned point 2 because currently the combination of 1 AND 2 makes it impossible to get a comment out of sight. So if you remove restriction 1 OR 2 then deletion is more or less possible. Of course only restriction 1 prevents deletion strictly. But on this occasion I would also remove restriction 2 because I consider it as "intellinonsense", that is, as a pseudo-clever feature with the following properties:

  • Intellinonsense has no substantial benefit.
  • Intellinonsense hinders the user.
    In this case it makes it impossible to indent certain comments. For example with SVN log messages I follow the convention to indent the log messages for garbage changesets (bad idea; committed to wrong branch; ...) and the corresponding reverted changesets.
    Although I use the comments for the SlickEdit Backup History rarely, I would not give this little freedom away without a reason.
  • Intellinonsense is a waste of developer and user resources.

Of course it does not make a big difference in this specific case. But it's about the general attitude.

PS: If you really want to trim something then I would suggest to trim only the trailing whitespace. Before I commit my own source files I usually call the command 'remove-trailing-spaces' (bound to a button) and I already wondered why SVN does not offer a switch for that.
« Last Edit: April 29, 2009, 11:31:04 pm by jb »

David_O

  • Senior Community Member
  • Posts: 152
  • Hero Points: 8
Re: Flaws of 'Add Comment to Selected Backup'
« Reply #4 on: April 30, 2009, 05:27:29 pm »
A fix for removal of backup history comments and a change to preserve leading whitespace will be included in the next release.  In a future release, we will also take a look at the command names to see if changes are needed.

Thank you again for the feedback.