Auto-Backup Feature Opinion

I tried to use the Poll feature but it doesn't seem to work, so please provide your feedback as a response.

Auto-Enable yes

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.

1. Enable Auto-Backup

* system-wide, with exceptions per workspace.

Or

* Enable by default and allow to turn of per workspace.

2. Number of Backups to Keep (default 5)

+ 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. :)

Sure.  :)

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.    

Hi.

"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?

From the visibility-to-others perspective, it seems likely that we would use that at the Workspace level.  

As far as using zero for the default number of backups to keep, I was thinking zero meant none.  I may have misunderstood the question though.  I thought it either 1. Enable Auto-Backup or 2. Number of Backups to Keep (default 5).  If having both switches in place is the thought, then one switch that says on-or-off and another that indicates how many to keep if the first switch is on seems fine to me, and 5 seems like a decent default.

We save all the time so that would mean *a lot* of versions. Why not make it part of the development process by "staging" a file explicitly ("pre-check-in").

Simon, can you explain further what you mean?

Thanks.

1. Enable at system level and disable per workspace.

2. Infinite numbers on current day + one per day on previous days. Demands a little housekeepring on first save on a new day and raise a problem for them working over midnight, but that could be solved with definitions of new day starts at 3am etc.

Ah, I was more thinking about git staging so making it explicit before commiting. githowto.com/staging_and_committing

Not sure if a plain backup feature makes sense for a version control system.

Just saying...

"Not sure if a plain backup feature makes sense for a version control system."

It's a good thing we don't have just a plain version control system then. :)

The backup idea is based on customer requests and the need to revert back to a previously saved version that has not been committed. This also allows WIP code to get backed up with the DB backup instead of separately.

Thanks Bo. That makes sense. It seems like a few of you are on the same page.

"Not sure if a plain backup feature makes sense for a version control system"

Instead of backup you could look at it as version control for WIP object :-)

Hi Jeff,

Regarding "This also allows WIP code to get backed up with the DB backup instead of separately" What about non-progress objects?

- RTB do not know when non-progress objects are saved.

- It could be connected with the "unlock object" but I do not think that will be a good idea.

- What about an external "Save object button/action", I expect that you will not save anything unless object is changes, so it should be penalty free to have this option.

This is just to be considered for later version, we will still have our daily zip (one per weekday), Carl his OS-Backup and other their solutions. If a backup-up of the RTB database should cover all WIP we need a way to support non-progress objects.