I have the habit to quite frequently duplicate a project, when progress is enough to call it a v1.1, v1.2, etc, and store away the older versions in a folder for reference.
Now, when I work on the current version of the project and want to check something in an older version (“hey, I tried this and that some 2 or 3 months ago, have to see if it fits in now!”), I locate the old file by the modified date I remember (what usually works not to bad), open it, and close it again after having found the bout of text I need - without making any modifications to it.
The problem is that scrivener now assings the current date as new “modified date” to the file. Thus, my vaguely remembered order of “old versions” is corrupted, and intuitive search of older versions will not work any more.
It doesn’t help to use the “created dates” for indentification instead, as duplicating the project will always maintain the original created date of the project.
Any ideas / help? Would it be possible to allow scrivener not to change the modified date in the case when there are no changes made in the file?
First, I’d recommend reading this article, which contains some tips and strategies for working with multiple copies of a project on your drive; it’s not entirely salient to your question, but might have some useful tips for you. Primarily, I’d suggest using the built-in backup feature instead of duplicating the project and ending up with a bunch of serialised project names in Finder, which can be confusing unless you maintain an external index of these files. For one, the [b]File/Back Up/Back Up To...[/b] command will automatically timestamp the name of the project backup for you. Since this is stamped when created, and is part of the name, it won’t change if you open it and poke around. Further, the backup feature creates these backup projects rather than duplicating them, so you’ll get a proper creation datestamp at the filesystem level as well.
At any rate, just opening a project is in effect “editing” it. Since a project is in part your interface choices, and interface choices include what you are looking at and what text you have selected, if you go in and change those parts of your project, they must be saved into the system and thus the modification date changes.
Even if you don’t use the datestamped name and zip features of the backup tool, the fact that it sets the creation date to now instead of the original project’s is probably reason enough to use it—plus you can spool off milestone copies while you are working, you don’t to close the project, navigate to it in Finder, and duplicate it. In fact, I use this command so often I’ve set up a keyboard shortcut for it.
Ok. Didn’t have that in mind. You’re right, in this case there is no way around the modified modification dates.
That sounds like the solution for my issue! In fact, I use the backup option every day, but only to have backups of the working version of the project sent to my dropbox - as zip files. I should in fact use it as well for my “milestone copies”, and sort them not by mod date, but file name. The only difficulty I see is that I sometimes change the name of the project itself, so in a certain measure the order will get messed up. But I’ll find a solution for this (maybe just sticking to one name? 
)
Thanks a lot for your answer - quick, concise and exhaustive like always. Great!
If you’re using “Backup Project To…” rather than just relying on automated backups (which you won’t want to do for milestones anyway, if you have the automated backups set to store only a limited number, since the older copies get deleted as new ones are made), you can change the name of the backup file, so you could use (formerlyX) or a version number there as well as having the date stamp. If you stick the version number at the beginning and use leading zeros, you can keep them in the right order when they’re alphabetized in finder. (Eg. 001projectname21-06-11.scriv, 002newprojectname22-06-11 will still be ordered with 001 before 002 even though alphabetically “newprojectname” comes before “projectname”.) Of course, you do then have to remember what version you’re up to. 
That’s the point! I’am afraid that would never work for me. But what I am trying to do now, is adding some remark after the time stamp, that allows me to identify the “build”.
For all future milestone copies that should work out. For my archive of older copies I did not find a solution yet. Will have to live with it. It’s not really a serious issue.
Heh, yeah. It wouldn’t for me either.
What you might do, moving forward–and even backward, if you can devote a little time to it–is start a list (inside your project or externally) of the milestones. Just create a new document and bang out a list of the back up files–even link to them, if you like–and a description of where the project is at, why it’s a milestone, whatever. (Maybe the good old, “saved version before I attempt such and such”.) You can open your old backups and write the description then based off what you see, and going forward you can just add the note to the list when you make the new backup.