How do I get DW to save backup versions of the files I am editing?

[Galeodan]

How do I configure DW to save backups of files, so I can rollback to a previous version of any file (HTML, CSS etc.)? I don't see anything in preferences.

[B i r n o u]

one of the way to handle back up and versionning is to use GIT . Dreamweaver has integrate GIT since some builds now, and facilitate its use directly from the User Interface. https://helpx.adobe.com/dreamweaver/user-guide.html/dreamweaver/using/git-support.ug.html

but you will also have to understand what is GIT if you never heard about it. https://www.git-scm.com/book/en/v2/Getting-Started-What-is-Git%3F

Otherwise, you can always set up your own method, by regularly backing up your local site to an external drive. Beware, this will quickly become complex, because of the multiple files linked to your host file themselves evolving independently over time within your application

[Nancy OShea]

My local site folder is backed up nightly to a cloud server.  And the backup files are retained for 30 days in case I need them.  

For a 3 page website, I don't think you need an elaborate version control system.  Use File > SaveAs and give files a new filename that includes date & time (eg.  custom_styles.4.26.4pm.css) or whatever designation you like.

[B i r n o u]

yep, the only problem , eother wth three files, is when your external files evolve in fonction of the hosting files... it's often a mess, when rolling back the hosting files and not the dependant files... and so on...

[osgood_]

yep, the only problem , eother wth three files, is when your external files evolve in fonction of the hosting files... it's often a mess, when rolling back the hosting files and not the dependant files... and so on...

By @B i r n o u

I've never personally found it a mess and I build websites of considerably more than 3 pages so I can't see why it would be a mess. Whatever method you use, if you're organised it should work perfectly. Of course if youre not organised then poo happens.

Maybe it would become a mess for you considering you're using poopack compilers and command line stuff, node js flooded with files and folders, dependencies which you have zero idea what they contain. I can understand that might become a bit of  a mess, yes, but a simple workflow, as it can be...........

[B i r n o u]

well simply in a basic basic steps...

having an HTML file in v1 containing HEADER, ASIDE, MAIN and FOOTER.

So CSS just place the grid layout and some typo

now we move to HTML v2 containing not anymore the ASIDE due  to a dynamic linking MAIN content

so the JS has a basic interaction to fillup the ASIDE on the fly accordling to the MAIN content

now we're back in HTML v1... the JS pump an empty room... mess starts...

[osgood_]

I think you must be over complicating the building process Birnou. I've been building websites for 20+ years and I've never had issues that arent easily resolved, without the use of all the overload, compliers, git, decompliers, dependencies, plugins, frameworks, node etc....its so funny, just been watching a rather complicated process of a chap building a covid tracker with vuejs, moment, cli etc which can be achieved in a much more less complex and easier for everyone to understand vanilla javascript workflow........humm I dont know what happened or is happening to web-developemt, I really dont. These days its not about the code its about the file management and doing anything other than what a developer is meant to do, code.

[Nancy OShea]

When you make mistakes during an editing session, use Ctrl / Cmd + Z to undo and repeat as required.

For more Undo options and History states, go to Preferences > General tab (see screenshot.)

[Galeodan]

The situation I am trying to avoid is that which I suffered yesterday. In the process of attending to other tasks, I inadvertently deleted a chunk of code and exited DW before I noticed. I don't recall DW asking if I wanted to save the files but then I didn't realize I had damaged one of them and maybe just said <yes>. I noticed pretty much immediately after but I had already lost a chunk of work which would be difficult to reconstruct without a very recent version of the file, preferably the 2nd-last one saved. 

A number of applications can automatically save the last 1, 2, 3 etc. versions of any file you are working on. I hoped DW might have the same facility but could not see anythng in Preferences. I will checkout Git but I suspect it might be overkill, or maybe no help, for the circumstance I am trying to avoid. I do backup nightly but I needed a file version much newer than the last backup. I also keep backup versions after each significant edit but even they would not have been much help. Luckily, I had uploaded a very recent version of the file and was able to recover pretty quickly. It could have been a lot worse.

Maybe there's an extension? 🙂

[osgood_]

The situation I am trying to avoid is that which I suffered yesterday. In the process of attending to other tasks, I inadvertently deleted a chunk of code and exited DW before I noticed.

Well nothing will help you there unless you have used some method to back it up, regardless of what method you choose you have to manually instigate it or hope something like time machine (on a mac) was doing its job near to the time you didnt save your work.

I think what you are asking for is 'does Dreaweaver have an inbuilt backup system that monitors and saves a back-up file every so many minutes'? If so I dont know, one of the other contributors that use DW may be able to answer that.

The situation you found yourself in is a bit like the power suddenly going off without you having time to save your work, whether using a simple back-up workflow or a more complex one like git, which involves commiting the changes and pushing the file to git.

[Nancy OShea]

Providing your file has been saved at least once, Dreamweaver has an auto-recovery feature when the power goes off.  I've used it many times.  But DW does not make backup files for you at regular intervals and I don't know of any code editor that does. That's something you must initiate on your own.

If you uploaded an old version to your remote server, perhaps you can use that to help you recover your lost code snippet.

[Galeodan]

Power cuts, though frequent, aren't such a problem as long as my UPS batteries are OK. But thanks to programs which freeze up or shutdown I developed the habit of saving after every significant edit, so I don't lose that much. Trouble is that if I unwittingly save a corrupt or damaged file it overwrites the last save I did and now I have a problem. It would also overwrite the contiuously autosaved file if autosave was active. Some app's give you better protection against such accidents by saving a backup, with a different name, every time you save the file, so you always have the previous version or versions to fall back on. I thought maybe DW had such a facility, configurable, or maybe even invisible to the user. I have sometimes considered getting Timeline, maybe now's a good time. In this case, I did have a pretty recent copy on the server - Just luck.

[osgood_]

But DW does not make backup files for you at regular intervals and I don't know of any code editor that does.

I thought I'd check out Php Storm and Web Storm today as they have a ton of features in them that I've never used, don't even know what some of them do, BUT I found they have a 'local history' option which tracks all your changes to a file as you build the file and saves every change and dates those code changes automatically. You can roll back or forward to any saved/dated version of the code since the files inception.....a rather kool feature, there's no intervention from the user, no saving needed, no committing, pushing, pulling.

I'm assuming it must have a cut off point whereby once its reaches a maximum the oldest version gets binned but I dont know as Ive never used/studied the feature. Well I say I've never used it, its been automatically tracking and backing up the code changes, without me really knowing.

Probably for a small to medium website, together with a nightly offsite back-up solution, its probably more than adequate.

Below is the info about the 'local history' option lifted from Jetbrains website:

'Unlike version control systems, which only keep track of the differences made between commits, Local History offers much more. It automatically records your project's state as you edit code, run tests, deploy applications, and so on, and maintains revisions for all meaningful changes made both from the IDE and externally'.

[Nancy OShea]

Dreamwaver also has History.  That's what the Undo uses.  But it resets when you close the app.

[osgood_]

Dreamwaver also has History.  That's what the Undo uses.  But it resets when you close the app.

By @Nancy OShea

Right, in the 2 Storms everything appears to be retained. I can close the editor go and listen to a Led Zep album, come back 2 days later, open the editor and all the versioned changes are still available.

However its NOT forever, if you install a new version of the Storms you will lose the versioning, so it has it's limitations but its another back-up option to consider if you want an editor that can retain and track changes for small/medium website builds and you forget to save regularly or commit, push regularly etc. It might be useful but Ive never needed it and I'll just carry on backing up as I've always done. Its running silently in the background when I use a Storm anyway.

[Galeodan]

Dreamwaver also has History.  That's what the Undo uses.  But it resets when you close the app.

By @Nancy OShea

I notice Visual Studio Code will save the undo stack when you close the file and reload it when you reopen the file - But only in the same session (before exiting the App) - Better than nothing. DW dumps the stack when you close the file, even in the same session. 

[Galeodan]

BUT I found they have a 'local history' option which tracks all your changes to a file as you build the file and saves every change and dates those code changes automatically. Y

By @osgood_

Thanks for investigating. That definitely would be a cool feature. I'll check them out. Maybe there is an extension for VS Code (which I have been using quite a bit). I make regular "bookmark" saves, changing the filename each time, but an automated feature would be better. Undo isn't much help if you don't discover you have a problem until after you have exited the app. And last-night's backup doesn't give me back the work I did today.

[Nancy OShea]

Get a dedicated Real-Time Backup system that saves files at regular intervals.  My file backup system can do Real-Time, too, but I turn it off to save on resources. 

[B i r n o u]

Sorry, this is a bit long, but the idea is to put it all together to better understand what we are talking about.

Backup and versioning methods during the development phases of web sites and applications has always been a real headache. Moreover, it depends if you are the only one working on the project, or if several people are working together on the same code pages. When I talk about code, I include HTML, CSS, JavaScript, server language, database and client/server communication languages.

As far as the development itself is concerned, there are two main approaches:
on the one hand, the old-fashioned (it is not pejorative) development which consists in basing oneself on a well-defined set of specifications (we know more or less where we are going, and how to get there),
and on the other hand, a more recent method, which was clarified about twenty years ago, through the agile manifesto, which allows you to constantly adapt as you develop to the 'evolving' needs of the client.

So of course, depending on your approach, the backup processes may be based on different methods and conventions.
For my part, for years, with the teams I have worked with, we have relied (depending on the team) alternately on CVS or SVN.
There was a time when Dreamweaver integrated a version of SVN (I think at the time of CS 4)... it wasn't so nicely implemented... but it was a start...

From now on, and for the last fifteen years, there is GIT, and it goes without saying that the world of backup and collaborative work has made considerable progress.
Well, all this said, it doesn't bring much, except to stir the air... a lot of theory... and little practice.

so as Nancy says, it is up to each one to organize himself according to his wishes, and to adapt as well as possible according to his own work process.

the problem in web development is that there is a host file that includes external, interdependent and multiple files.
making an incremental backup of this host file will not solve the interdependencies of the external files, in case of a roll back to a previous version.

To explain this problem by example, let's take a very simple case of an interaction between an HTML file and a simple CSS file. Let's keep it very basic.

i.e... say that one have a v1 html construct as this following code

<!doctype html>
<html>
<head>
<meta charset="utf-8">
<title>v1</title>
    <link rel="stylesheet" href="styles.css">
</head>

<body>
    <div class="bloc">The bloc is cyan</div>
</body>
</html>

and the CSS file linked to it as

.bloc {
    width: 100px;
    height: 100px;
    background-color:cyan;
}

our first version is finished... so the best way to save it is to clone the whole folder (including the HTML and the CSS files), and to start again on the clone of the whole folder. Because if we save only the HTML file in v2 and we progress the file by modifying its content in the following way

<!doctype html>
<html>
<head>
<meta charset="utf-8">
<title>v2</title>
    <link rel="stylesheet" href="styles.css">
</head>

<body>
    <div class="bloc">The bloc is now red</div>
</body>
</html>

then, of course, we adapt the CSS file accordinly

.bloc {
    width: 100px;
    height: 100px;
    background-color:red;
}

everything is saved... and that's fine...

but... if we decide to get back to the previous HTML file and so, if we now roll back the HTML file in v1... the process is broken, because the text will be The bloc is cyan... but the color in the dsplay will still be red.

we realize that during the evolution several files have been modified and so all of them have to take back their state at the time of the saved version of the host file. Hence the simplicity if the integral files are put aside and used (integral folder, HTML and CSS), and not just the intermediate version of the host file.

so imagine when we have tens of files in the projects, not saying hundreds...

that's why Dreamweaver's history allows us to swap each of the modifications within each of the files (it's a bit confusing but it makes sense).
It's a pity that this history is lost when one close the files, but that's where GIT can take over.

not to mention GIT... if you adopt the approach of saving by folder at each important stage of the project, and then use a good comparison tool (for example ultra compare), one can easily find all the changes that have occurred between the various files... this is where GIT becomes very useful once again, especially if several people are working on the project and need to merge previous and current version of the apps...

but once again, and as OS mentions, especially if you work alone, a bit of organization and a well laid out method can also help with versioning, and to go back if the project goes haywire.

now and to conclude, as far as I'm concerned, I find it perfect that Dreamweaver doesn't offer an autosave feature, I prefer to control exactly when I decide to save, file per file...

[osgood_]

That's not my method of workflow. I work with all the css, javascript, html code in one file until such time as the construction is finalised/approved, then I move it to external files. Mostly after that there are only minor changes which are relatively easy to manage, or I can roll-back to a version where all the code is cited together.

I find it much quicker to work this way, where all essential code is in one location, rather than having the tedious problem of having to keep locating, opening extra editor tabs, trying to manage several key files independently at one time. Thats a very confusing, slow workflow in my opinion.

The only issue I would have in reference to having no autosave is you HAVE to remember to save your work, rather than it being automatically backed-up regularly. I use both options, manually save at various intervals, plus have Time Machine back up automatically. Now it looks like when I use any of the Jetbrains software I can have a third fall-back method, without having to depend on more dependenies in my site folder, which in my opinion, just creates a management issue and a mess to start with, which is what you call a 'more recent method'.

I guess its each to his/her own. I'm seeing really worrying 'advances' in web-development, which are more complex than they need be. Yes IF you work in a large team, have blue chip clients then these methods would be applicable, in some cases. However many independent developers, small teams take their lead from these large co-operations, thinking this must be the correct process and then use those to process something which can be produced in a less bloated and unnecessarily complex way

[B i r n o u]

interesting, just a question how do you share the common parts between pages? if everything is in the same file, nothing is shared? so you duplicate the common resources. well, as you say, each own has his own method.

[osgood_]

Well normally once a common parts css/javascript like a nav, footer, slideshow is established/approved I can link that css/javascript file to each page and it doesnt need editing any longer to the extent that it will usually complicate the process, not that I've found in any case.

I can then use blocks of embedded css/javascript to style each individual page that do not share the common styling and move it to a global stylesheet once approved, which is linked to the page or if its a complex page it gets its own linked stylesheet but I prefer to keep it to as few as possible stylesheets.

So no, I dont really duplicate the code I just link it as and when the component structure/design is finalised and approved. If needs be and push comes to shove and some radical changes are required, Ill just bring back the css for the component - nav, footer, slideshow etc work on it in situ until approval and then transport it to the linked stylesheet. So I nearly always have all the necessary code for the components in the same file. The kind of websites I used to produce dont get updated very often in terms of design, only content.

Edited: Thats kind of how vue.js works if you use the cli version - the css can be kept along with the html for the component. I dont know what happens after that as I ve never used the vue cli version only cdn, but I would assume it gets written, by some package dependency, to a global css file, maybe.

If another page needs to be added at a later stage, again the common parts are already present and correct I just use embedded styling again and then move it to the global css file or its own css file depending on how complex the new page is.