One of the great new features coming in our next release is the Auto-Backup feature. When enabled, this feature will store your WIP PCODE changes in the repository on each save. This will allow you to go back to previously saved versions if you really mess something up, allow others to review private code you are working on, and ensure that all WIP changes are automatically included as part of your daily repository DB backup.
Up for discussion here is where the preference to enable this feature should be set.
Currently, there are two preferences:
1. Enable Auto-Backup
2. Number of Backups to Keep (default 5)
As a Roundtable user, would you prefer this at the System level, or would you prefer to enable on a per Workspace basis?
Jeff Ledbetter Product Architect | Roundtable Software
Thanks Bo. That makes sense. It seems like a few of you are on the same page.
I tried to use the Poll feature but it doesn't seem to work, so please provide your feedback as a response.
Infinite backups if it cleans up on check-in (or a configurable number with infinite possibilities).
Eclipse keeps this already in team history. I've made a stupid change then hit save a few million times. I've scrolled down to the previous day to find the pre-dumbifed code.
System-wide or per Roundtable Workspace?
Yes, the idea is to clean them up on check-in.
Correct, Eclipse keeps in its local history but its private to you and not stored in the db. Imagine the consequences if you are eaten by a rabid armadillo on your way to work!
I would think the armadillo would end up being an upgrade in developers for us. Our real problem is our rabid outsourced IT. Every day that my private workspace is still there when I show up for work is a good day (so I want it in the RTB DB!).
If "per Workstation" translates to "per User" then Workstation for me. Otherwise I would like it to be configurable at the User level. It could also be configurable at the system level with an option to allow/disallow each user to override the settings.
* system-wide, with exceptions per workspace.
* Enable by default and allow to turn of per workspace.
+ One per day. during a day a source will be saved frequently so 5 backups will quickly start overwriting previous day versions. Most developers leave sources in some kind of viable state at the end of the day. Previous day can be more usefull to return to.
I create an OS-backup of all changed sources (find src -type f -mtime -1), I've been doing that for about 6 years and haven't yet found the need to remove any of those backups, it only takes 2.4GB
3. have an API to update workspace settings so that we can "for each" the setting without have to resort to for each rtb_wspace ...
4. Will it be possible to compare a source with previous versions
Number of Backups to Keep (default to zero) would be the preferred switch for us.
Configurable at the User level would be more useful for us than at the Workspace level or the System level.
Would 0 mean not enabled at all, or unlimited number of backups should be kept?
Per "Workspace" not "Workstation". :)
Keep in mind that an alternate purpose of the auto-backup is to allow others to review your changes in your Lab or Task. No "ninja developers" here. It's important to know what others are doing. :)
Well that makes more sense....my apologies..
What Ninja? :0)
I was coming at it from the Eclipse Local History feature point of view; which is why thought user level. We do all of our development with the task folders on a network drive so others have access to them in the Tabletop environment..
If this is part of the solution to the difficulty of sharing WIP files in the PDSOE environment for code reviews and such, then I could see setting it at the System level with overrides at the Workspace level.
0 being NONE, infinity seems a bit much.
"If this is part of the solution to the difficulty of sharing WIP files in the PDSOE environment for code reviews and such, then I could see setting it at the System level with overrides at the Workspace level."
It's part of a solution for more visibility to management and fellow team-members, and to ensure the safe-keeping of WIP code at the Task or Lab level.
Well that's as fine as frog fur, when can we have it?