Delete Version

Submitted by muunkky on 28 April 2009 - 3:40pm

I understand that I can save my work as many times as I like, but if I want to export I need to commit to a version. Versioning is a great feature that I look forward to using.

When I normally use versioning I create several versions per day. Every time I make changes to the code I check out the files I need and compile them on my localhost until everything works, then I sign the files back in and commit to a new version. The difference is that when versioning for code like PHP, I can make many edits between versions as I test, but with SQL scripts I have to export every time I want to test.

PHP editing:

  1. CHECK OUT
  2. Make edits
  3. Compile locally
  4. Debug
  5. Compile locally
  6. Debug
  7. Compile locally
  8. ...
  9. COMMIT AS VERSION

SQL editing:

  1. Make edits to SchemaBank
  2. COMMIT AS VERSION
  3. Forward Engineer
  4. Debug/Review errors
  5. Make edits to SchemaBank
  6. COMMIT AS VERSION
  7. Forward Engineer
  8. Debug/Review errors
  9. Make edits to SchemaBank
  10. COMMIT AS VERSION
  11. Forward Engineer
  12. Debug/Review errors
  13. ...

It becomes clear that versioning with SQL requires many more versions than with regular coding:
Proposed solution:
Allow the user to "Copy over" the most recent version with minor edits. When I click "Commit as Version" I could get a dialog box asking "Would you like to replace the most recent version? (minor edit)"


Login or register to post comments

Comments

Overwriting the most recent version...

Submitted by karl on 30 April 2009 - 9:50am.

was actually supported at pre-beta stage. The reason of dropping that feature, as I recall:

1) if a committed version is overwritten (i.e. modified), all saved diff report and alter scripts would become invalid, although you can always re-generate them

2) we want to follow the metaphor that once a schema is committed as a version, it will stay there forever and can always be retrieved / traced back. Apart from being a good change management practice, it also let us build some very interesting features on versioning (stay tuned!)

But I totally agree with you that schema design might need more commit iterations than traditional source code versioning system.

Then it comes to how many versions each plan should give. While I know the word unlimited would be tempting, do you want to share with us your thoughts?

:)

Hard and Soft Versions

Submitted by muunkky on 1 May 2009 - 1:12am.

Perhaps there is a middle ground.
If there were two types of versions. A "hard" version could be used for diff reporting and alter scripts as well as any other built-in features while a "soft" version, or a "dev" version could be exported but without any support for diffing across branches, altering, reverting, etc.

That way you could keep the limits the same for each account type, but only count "Hard" versions.

I like this solution because it allows me to use the web interface for my development needs instead of just as a repository. I know you allow a large amount of versions with your pay accounts, but I think there is a "fear of saving" when you know there is a limit, no matter how big it is, and it might be discouraging for users to use it as a fully integrated tool.

under discussion

Submitted by karl on 5 May 2009 - 6:22am.

a very nice suggestion, we will try to make a decision by this week.

thx so much :)

Purging a branch

Submitted by karl on 11 May 2009 - 10:13am.

We are planning to allow purging all versions under a branch AND copying a version from one branch to another.

As SB allows you to have unlimited number of branches, you can assign one particular branch (say, dev) for everyday design and committing your work into it.

When you are sure a version works perfectly, you can copy it to another branch (say, production).

You can at any time purge all versions under the dev branch so as to reclaim the version usage.

That's a great solution, I'll

Submitted by muunkky on 11 May 2009 - 3:37pm.

That's a great solution, I'll try that out.