B6: Mac file-> refresh/revert grayed out, can't revert modified file.

[tim_k]

repro: open a file, modify it, don't save it. Try to revert by selecting file->refresh/revert - it's grayed out.

The same steps work as expected in the Linux version.

-Tim

SlickEdit 2014 (v19.0.0.9)

Serial number: FE56917_BETA
License type: Beta License
License expiration: 2014-11-02 02:36:00
License file: /Library/Application Support/SlickEdit/19/slickedit.lic

Build Date: September 29, 2014
Emulation: Mac OS X

OS: Mac OS X Mavericks
OS Version: 10.9.5
Processor Architecture: Intel(R) Core(TM) i7-4771 CPU @ 3.50GHz 64 bit (8 cores)

Memory: 80% Load, 26470MB/32768MB Virtual
Shell Info: /Applications/SlickEdit2014.app/Contents/MacOS/secsh -i
Screen Size: 1920 x 1080, 2560 x 1440

Project Type: Verilog: Model Technology ModelSim
Language: .sv (SystemVerilog)

Installation Directory: /Applications/SlickEdit2014.app/Contents/

[patrick]

Odd.  Does it continue to happen to you if you restart the editor on the Mac?  What type of file were you trying to revert, a verilog file?

We can't reproduce it here so far, but we're still reviewing the code for it.

[tim_k]

I tried it in both SystemVerilog (.sv) and Verilog (.v) files, in the same project in the same session.

Since I reported this, SE has frozen twice (spinning beach ball of doom) requiring a force quit. I have the reports if you want 'em. Since then, I can't repro the revert problem.

Also, I think I might be pushing the boundaries of expected use...

I have SlickEdit running on a Linux VM running in VMWare on the Mac, and SlickEdit running natively on the Mac, both sometimes with the same workspace open. The workspace is resident on the Mac file system, mounted on the VM via VMWare Tools. This has worked well in the past on v18, but I didn't stress it as much as I have been while working with v19Beta. I'm wondering if I'm creating conflicts that SE just wasn't expected to handle.

Thoughts?

-Tim

[Clark]

Very bad things will happen if you have two SlickEdit instances with the same workspace open like this. In this case, SlickEdit probably doesn't even know that the workspace is opened elsewhere and both processes will be writing to the same tagging database.

[tim_k]

Yeah, I was afraid of that. I'll have to make separate workspaces for the Mac & Linux instances.

-Tim

[tim_k]

Having to duplicate workspace files got me thinking about cross-platform backup history...

What I'd like to do is have SE save backups in the same directory (or a sub directory) as the source, and be recognized by both SE instances (not simultaneously :-) ). So if I make edits on either platform, the other can see the same backup history and be able to revert/diff/etc. to the appropriate version. However, it does not appear to be an option to have a custom directory for the "create backup history on save" option in the file options just the global directory, yet it's there for "create backup file on first save". I want the granularity of a backup every save, but I also want to put each file's backup in a sensible location. This doesn't seem possible with the current options, am I missing something?

Thanks,

-Tim

[Clark]

Set the "Backup directory path" (Options>File Options>Backup).

[tim_k]

Excellent! That works as I'd like. The docs, however, could use a little cleanup as this is not clear in either the live help in the dialog or the browser help that this is how that option field works. The "Backup location" and "Backup directory path" options appear to have similar purpose, and the help (file:///opt/slickedit/help/WebHelp/ch12s11.htm#fileoptionsbackup) contradicts the behavior of the dialog:

Backup directory path - Specifies the path to the directory (including the drive, if you wish) in which to place backup files when Make backup files is enabled and one of the "Global" Backup directory options is selected.

You can only select one of the "Global" directory options if the "Create backup file on first save" is the option selected.

Really, I'd love to have "Use child directory" as an option for "Create backup history on save", better still would be to have all the options for both backup options. It seems to me IMHO, that the location of backup file storage should be independent of the frequency of the backups.

-Tim

[tim_k]

OK, now is there a way to migrate the change history from the former global location to the new local location? I tried copying the .vsdelta files into the new location, but SE doesn't seem to recognize them - I get zero history versions for files with many revisions in the .vsdelta file.
[edited to add...]
And when I try and look at the backup history browser, I get this erorr: Invalid XMLCFG handle. Clicking OK, gives me a backup history browser window that is completely empty except for some diagonal dotted lines in the top pane.

Thanks,

-Tim

[Clark]

Really, I'd love to have "Use child directory" as an option for "Create backup history on save", better still would be to have all the options for both backup options. It seems to me IMHO, that the location of backup file storage should be independent of the frequency of the backups.

The older backup options were for emulations for the most part. The child directory options was something we thought would be useful (but we didn't think it through).

Later, we realized that there are problems with creating backup files and backup directories all over the place. On networked file systems, these backup options cause files/directories to appear all over the place. System administrators and other users really don't like this. Therer can also be problems with permissions on networked file systems where backup files can't be created. Not to mention, unless you have a special tool, it's hard to get rid of backups which are all over the place. That's why we decided not to add these older directory options.

[tim_k]

Reasonable enough.

Is there a way to migrate my existing history to the new location?

-Tim

[Graeme]

You can still get it to backup to a child directory with "backup on save"  - specify ./slick-backups/ as the "folder to backup to".  Works for me on Windows anyway.

[Dan]

OK, now is there a way to migrate the change history from the former global location to the new local location? I tried copying the .vsdelta files into the new location, but SE doesn't seem to recognize them - I get zero history versions for files with many revisions in the .vsdelta file.
[edited to add...]
And when I try and look at the backup history browser, I get this erorr: Invalid XMLCFG handle. Clicking OK, gives me a backup history browser window that is completely empty except for some diagonal dotted lines in the top pane.

Thanks,

-Tim

Did you copy the whole tree, including savelog.xml?

[tim_k]

I hadn't, but just tried with no change in behavior.

The old setup was just the defaults - saving to ./slickedit/19.0.0/vsdelta/...
I changed the backup directory path to './backupfiles/' (essentially what Graeme posted) which created the backupfiles directory at the root of the workspace, and it's populated with changes to files since I changed the backup directory path.

I tried copying the .vsdelta files for workspace files from the original location to the new location, in hopes of keeping that history, but got the errors described previously. I just tried copying the entire vsdelta directory from the original location into the new location, and copied  the savelog.xml as well, giving me ./backupfiles/vsdelta/... and ./backupfiles/savelog.xml, mimicking the original structure. No joy. Same xmlcfg handle error. I tried moving everything from within vsdelta up to backupfiles, and got the same error.

The good news (as expected) is that putting the backup files in the workspace does allow both Linux and Mac versions to see the same history.

-Tim

[Dan]

So you set the backup path to a relative path?  I'm not sure that's been tested.  I think you might have better luck if you used the same path, but an absolute path.  There may be places where the path is calculated by appending VSLICKBACKUP (the environment variable we use internally) with the "other" path.