Proposal for a new "Save New Version" feature

Previous topic - Next topic



I like to keep various versions of a document at different stages in its development. This means that I can easily go back to a previous version to, for example, see if I liked something better as it was in the past compared to how it is now, or to copy something from a previous version that I've since deleted but now want back.


At present this is a bit awkward.

Once I've got a document to a certain stage in its production I use "Save As" and increment a number at the end of the filename to create a new version. E.g. document1.sla , document2.sla , etc.

This means that I need to:
* go to the File menu;
* select Save As;
* click in the filename textbox;
* delete the current numerical suffix;
* enter a new numerical suffix;
* okay the dialog.


Add a new "Save As With Incremented Suffix" or, more simply, "Save New Version" function.

This feature would automatically add a numerical suffix to the filename if one didn't already exist or increment an existing numerical suffix and save the document under the new name.

This would make it much easier to keep a running list of different versions of the same document.

(Blender has a similar function where you can increment/decrement the suffix using some buttons but that's unnecessary for the sort of thing I'm proposing. Just one menu item and/or button/shortcut is needed.)


The (very basic) pseudo code for such an operation could be something as simple as:

* Get existing filename.
* Split filename using space as separator.
* If last split section is numerical then increment by 1.
* If last split section is not numerical then add space and number 1 to end of filename.
* Save with new filename.

It doesn't have to be too fancy.


(the real one)

Use a revision system.

But the .sla file format is not really ready for it and there is no good revision system for binaries (image) and longer paragraphs.

(the other way round)

if something like this is to be implemented, i would suggest to make it a "save snapshot" or similar function.
the whole project is collected for output in a new directory, with a time stamp as a suffix.
(incremental saves could be possible for data that has not changed since the last snapshot)

it should be possible to add a comment to help browsing through old versions.

the user should always work on the same document but copies are created on the disk.
(myproject.sla is the real project and no myproject-proofread.sla should ever exist :-)

a basic "save snapshot" function as described above (without incremental optimization) should be easy to implement (basically a call to "collect for output"). if somebody coordinates the specification work, i can create a plugin for it.


A "Save Snapshot" feature sounds like a good idea but I would be worried about how much space the snapshots would take up. Sometimes I can go up to 20 versions of the same document which can contain lots of large images. Of course, good housekeeping will take care of that but how many people tidy up after themselves properly? I know storage is pretty cheap these days but I wouldn't want Scribus to be blamed for using up large chunks of people's storage. A nice idea though and it might be the way to go in the short term.

SIDEBAR: I don't know if you have ideas about how incremental saves could work but I've a feeling it could end up being messy when things like images get in the mix. For instance, make a snapshot containing an image, then make another snapshot where the image hasn't changed from the last one. If only the changes were saved, where would the image be? If it's only in the first snapshot then the second snapshot isn't a "real" snapshot because it won't contain the image. The second snapshot would have to reference the image in the first snapshot and that would be a bit of a mess.

I have no problem with the project.sla being the current version while past versions are given different names, e.g. project3.sla or project-2016-10-11.sla , or whatever but in my experience, when people do the same thing as me, they always treat the one with the largest number as the latest version. Maybe it's just a matter of getting used to doing something differently. I do things the way I do them because that's the way I've always done them. If technology has changed and there's a better way to do things then it's up to me to learn.

Being able to add a comment, as you say, to the snapshot/version/whatever would be a good thing.

A fully-functional built-in revision system would be fantastic. It would be great if I could just click on a drop-down box to select a snapshot to go back to and Scribus would put things back the way they were. And then I could just revert back the current version when I was done without having to mess around with versioned document names. Of course, that's just a dream but it's a nice one to have.

For anyone reading this and is wondering, you can actually achieve something similar using Git but it means having to switch between two applications. (See here for more info.) It's not a whole lot of extra work but the extra steps can mean that it just doesn't get done out of laziness.

This is why I suggested the simple versioning "system". It's simple and works the way a lot of people work but if it goes against the Scribus ethos then I have no problems with dropping it. I just think it's an easy-to-implement feature that most people can understand. A first step rather than a giant leap but if it's a step down the wrong path then that would be a problem.

Does anyone have an example of an application that does something along the lines discussed in this thread? What solutions have other developers come up with? Do these solutions work well or badly? What are people's experiences of this kind of thing?


what you proposed is not against the scribus ethos.

but it's not a good idea to change the filename toto match the state of the file itself.
it's the most messy way of doing version control.
(only better than no version control... even if i'm not 100% sure of this either)

: - )



of course, using git for file revision is basically a good idea.

but you only get a complex way of rewinding the state of your file to an older version.

you cannot check what the difference are, cannot "cherry pick" the changes you want to discard / keep and do not improve collaboration.
(with code, the main target of git, you can do all that!)

i think that using a traditional backup system (every consumer system has such a tool built in!) is more comfortable for most users.

p.s.: yes most of my scribus files are revisioned with git. but i have never ever rewinded any of them... i only use git as the simplest way to share a project across all the computers i use... and with other people (but in this case you don't wish to have any merge conflict!)


I agree that it's not a good idea to change the filename to reflect the state of the file, it's just that it is what a lot of people do. This is probably partly because you can do the same thing across many applications so it becomes a standard practice (rather than a best practice). Having to learn lots of different ways of doing the same sort of thing can become tiresome.

In the past I've been in many situations where I've had filenames such as project6.sla , project6bnw.sla , project6rf.sla , etc. where project6 is the seventh iteration of the document, project6bnw is the same thing but with the images converted to greyscale, and project6nf is project6 but with different fonts. The different versions of the same iteration are used to check to see which looks nicer. Then I'll take whatever I think looks best and create project7 and move on from there. It's a silly way of working but it's just what I'm used to doing and it works across all applications. I would love to have a better way of doing things like this.

With Git you can see what the changes to the document were but only if you can understand the differences in the XML, which most users can't and I don't think any reasonable person would expect them to. It's fairly easy to "rewind" an SLA to a certain point too (as mentioned in the tutorial I linked to) - the SLA is just XML code after all - but, as you say, cherry picking which specific changes you want to keep/discard is difficult, bordering on impossible in most cases. It's mostly an "all or nothing" situation.

Being able to go back and forth in time over changes to individual objects within Scribus - rather than the whole document - would be a fantastic feature. I can't get my head around how that could possibly be achieved though.

You're also correct that most OSes come with backup functions that allow users to go back to a previous version but most that I have seen are very basic backups where only the last version is kept and then overwritten by subsequent saves. Something like OSX Time Machine is nice but a lot of people don't have access to that sort of backup system. (Time Machine, for people who don't know about it, essentially keeps track of every file throughout its life-cycle and you can choose the time/version to restore from.)

While having a facility to restore a backed-up file from a certain time might be useful, it's not really much good for what I want. Backups are made when the file is saved (if you're using a continuous backup plan) but how would I know which backup was the one I wanted? I regularly save my documents after most major changes (just in case) and so I would have hundreds of backups to choose from, all with slightly different timestamps. Do I want the version that was saved at 14:21:06, or 14:21:52, or 14:22:58? I wouldn't know and would have to check each one. That's not an ideal situation and I'd rather stick with my tried and trusted version numbering rather than having to trawl through loads of backups to find the right one.

I've been letting your idea about creating snapshots stew in the back of my head and I'm starting to think that might be a better way of working (although I'm still worried about taking up a lot of space). I'll let the idea sink in a bit more and maybe try some experiments.

Nermander: Thanks for posting the link. RCS looks interesting and LyX looks like it could be an interesting companion to Scribus for users who don't need a full page layout application every time. (Some recent posters seem to be needing something like LyX rather than Scribus for creating reports and academic papers. Here's the home page for anyone interested: )


a. as said, os x has time machine
b. windows seems to have file history
c. i guess that the mainstream linux distributions offer something similar (and if not, a quick search showed )

so, most users seems to have access to revisions tools outside of scribus.

still, adding such a function to scribus could be interesting.
i see three options:

- simply make revisions of .sla files (and list them...)
- simply making revisions of the full project (collect for output)
- make a completely revision of the .sla file and a revisions of what changed in the resources.

the first two seem to be easy to implement, once they're fully specified.
the third probably the best one but is a bit harder to get right (on multiple platforms).

as said, i can try to implement one of the first two (or one that lets choose between both)... but i'd like somebody to lead the project.


I think the third option might be going a bit too far. It could become so complicated that people simply don't use it because they can't understand what it is doing. I could be underestimating the average user but it sounds complicated to me.

The second option, "Collect For Output", for versioning pretty much already exists and people can do that themselves manually if they want to. In other words, if you want to take a snapshot just "Collect for Output" and save the folder somewhere convenient. I'm not sure that extra work needs to be done for that.

It's the first option that interest me more. I'm not sure what your thinking about it was but here's how I imagine it could work...

Add a new menu item "File -> Save With Recovery Point". (I'm not bothered if "recovery point" is called something else.)

When this is selected, Scribus:
* asks the user for a reason for the recovery point;
* saves the current SLA;
* copies the saved SLA to another filename (don't care what it's called as long as Scribus remembers it), probably within the same folder as the SLA;
* remembers the copy filename and reason.

The reason for the recovery point could be anything the user wants it to be, for example:
* "Before changing the fonts"
* "Before changing page size from Letter to A4"

Add a new menu item "File -> Recover From ->" that has a sub-menu listing the recovery points.

When a recovery point is selected from the sub-menu, Scribus:
* remembers the current name of the document being edited;
* closes the current document;
* loads the recovery point document (the copy saved earlier);
* renames the loaded document to the name of the document it's just closed.

I haven't put a whole load of thinking into this (it's very much a first draft) but I think it will work well enough for most people's needs (it certainly seems to do what I need) and it might not need a lot of coding work. It's not much more than remembering a list and performing some file functions.

All Scribus needs to do is keep a list of:
* Recovery Point filename (the copy that was made, so Scribus knows where to get it);
* Recovery Point time-stamp (so Scribus can list them in order for the user);
* Recovery Point reason (so the user knows what it was for).

I don't think Scribus should remember the name of the original document when the recovery point was made. If the user renames the document - for whatever the reason, maybe they misspelt it - and the recovery function undoes that rename then that's probably going to be confusing for the user.

P.S. I don't mind getting involved in this type of conversation - they bring up some interesting points - but I don't have much inclination to get more involved in actually getting stuff done. My proposals are just to see if the users are interested and to find out what they think about things rather than a "call to action".


Quote from: GarryP on October 12, 2016, 04:46:51 PM
P.S. I don't mind getting involved in this type of conversation - they bring up some interesting points - but I don't have much inclination to get more involved in actually getting stuff done. My proposals are just to see if the users are interested and to find out what they think about things rather than a "call to action".

You would have fitted in well in ancient Greece!    :D :D


... and no, i don't expect the person who originally formulated an idea to manage the project...

... as i am suggesting that i could do the programming, anybody reading this thread is welcome to take it in her hands!


keep on spreading ideas, discuss them and do not feel any pressure to do steps you don't want to do!

peace and love


What would the person in charge, or better, head of the project, should exactly do?

I am interested in helping, also because in this way I will finally test Scribus for real stuff that I am working on.