I read the long topic on the forum, but I still don't understand versioning.
Do I need to select a specific "variant"?
I have the deletion handling set to "Versioning" with naming convention "Versioning". I have not figured out what I should put in the untitled combo box in order to get the deleted files to appear in the same folder (i.e. preserve tree structure). If I leave it blank, I get this error when I try to sync: Folder input field for versioning must not be empty. Other combinations of things seem to put it in a subfolder of the root of the same drive letter as the source or a subfolder of FFS's installation location.
What happens when a file is modified, but not deleted?
Seems like this is a large enough topic with plenty of different interpretations, that some mention in the help file would be warranted.
Trying to understand versioning...
- Posts: 10
- Joined: 25 Mar 2003
-
- Posts: 2292
- Joined: 22 Aug 2012
If you select "Versioning", you have to tell FFS where to store the previous version(s).
That can be any existing folder on any local- or networklocation to which you have write access. Preferably that folder is initially empty.
The versioning location can even be the root of a drive (useful when using mapped drives).
If a new(er) version of a file is synced, FFS will now "move" the previous version of that file (if any) to the specified versioning location, while preserving the tree structure, relative to the "root" of your sync.
E.g., if you sync *E:\FolderA\SubFolderB* with *\\[ip-address]\FolderC*, the folder-tree structure as within SubFolderB and FolderC will be preserved.
FFS will not "copy" the tree structure to your versioning location, but will only create relevant (sub)folders according to need, i.e. if FFS will "move" one or more previous-version-files into that sub-tree.
If you select the YYYY-MM-DD method of versioning, your versioning location will contain all previous versions (if any) of files included in your sync, each previous version in its applicable location in the folder-tree.
The individual previous versions of any file can be identified by the date/time-stamp, as added to the original file-name.
If you select the default (?) method of versioning, your versioning location will contain the last previous version (if any) of files included in your sync, each file in its applicable location in the folder-tree.
The file-name is then simply the same as the original file-name.
It is OK (and probably even wise ...) to use different versioning locations for each of your syncs. But, it is not required.
That can be any existing folder on any local- or networklocation to which you have write access. Preferably that folder is initially empty.
The versioning location can even be the root of a drive (useful when using mapped drives).
If a new(er) version of a file is synced, FFS will now "move" the previous version of that file (if any) to the specified versioning location, while preserving the tree structure, relative to the "root" of your sync.
E.g., if you sync *E:\FolderA\SubFolderB* with *\\[ip-address]\FolderC*, the folder-tree structure as within SubFolderB and FolderC will be preserved.
FFS will not "copy" the tree structure to your versioning location, but will only create relevant (sub)folders according to need, i.e. if FFS will "move" one or more previous-version-files into that sub-tree.
If you select the YYYY-MM-DD method of versioning, your versioning location will contain all previous versions (if any) of files included in your sync, each previous version in its applicable location in the folder-tree.
The individual previous versions of any file can be identified by the date/time-stamp, as added to the original file-name.
If you select the default (?) method of versioning, your versioning location will contain the last previous version (if any) of files included in your sync, each file in its applicable location in the folder-tree.
The file-name is then simply the same as the original file-name.
It is OK (and probably even wise ...) to use different versioning locations for each of your syncs. But, it is not required.
- Posts: 10
- Joined: 25 Mar 2003
Thanks for the info. It sounds to me like it operates differently that was implemented in some of the betas that were discussed (downloads not available now?).
There was a feature request where Zenju indicated a %timestamp% variable had been added. He has also alluded more than once to the possibility of things like %baseDir%%relPath%%shortName%.%version%%extension%
[404, Invalid URL: https://sourceforge.net/p/freefilesync/feature-requests/315/]
Where can I go to determine the full list of variables that I can use?
There was a feature request where Zenju indicated a %timestamp% variable had been added. He has also alluded more than once to the possibility of things like %baseDir%%relPath%%shortName%.%version%%extension%
[404, Invalid URL: https://sourceforge.net/p/freefilesync/feature-requests/315/]
Where can I go to determine the full list of variables that I can use?
- Posts: 10
- Joined: 25 Mar 2003
The recognized "macros" (aka variables) can be found in resolve_path.cpp. A list of macros is also in the help under the "macros" topic. The macros in the "external applications" topic do NOT apply.
