Main Area and Open Discussion > Living Room
Versioning of files
Ralf Maximus:
Here's what I do... it's simple and has worked for years. Should be applicable to software development or any kind of document management.
Caveat: I am an army of one; this won't work for team development.
KEEP A WORK LOG. Start a Word document (or .txt or anything you want) and annotate the thing whenever you make a change. Include the date and any information a future version of yourself will thank you for now. My work log consists of a huge-ass Word table, one row per change. Every year I start a new one.
It requires some discipline, but should not be an onerous task. A simple note of what you did ("changed fonts on buttons of form x") will suffice most times; when you make major changes perhaps a bit more. I suggest this instead of renaming the actual project files, since that can get crazy complicated down the road. And no, I do not spend half my day typing comments into the log; it's the work of a few minutes, usually just prior to an archive function.
The payoff is this: Anytime in the future you'll be able to search for the date, perhaps a build number, and keywords to find when a particular bug/feature crept into the code. Using the build number, you can then track down the exact archive containing the source for that build. (Or the revision of the map file, or the latest tweak to Aunt Erma's cookie recipe.)
Archive? Yes. See below...
1. My work consists of a massive VB project, many files of varying types, any one of which might change during an edit session. The work log .doc is included within the archive.
2. When I feel the need for a backup -- prior to compiling, prior to release, or just because I'm nervous about some crazy stunt I'm about to pull -- I run a batch file that refreshes a .ZIP archive with all the files in my project.
3. When the batch completes, I rename the file with today's date, the current build I'm working on (#.#.#) and a letter A-Z denoting which build-of-the-day is in the archive. Sometimes I'll also add a comment in the filename, for example:
Backup 2007-10-02 v2.0.53a - Replaced all occurrences of True with False.zip
(Usually the renaming consists of overtyping the date and build ID; the work of a few keystrokes.)
4. Finally, the archive is copied to a 500GB backup drive on my network set aside for the purpose. I have archive files going back to 2002, including all the worklogs. The backup drive is in turn backed up multiple times to various places and media, including a PaperBack printout which consumes the warehouse next to my home. :-)
So how do I use this?
A typical scenario is that a customer calls and complains that feature x stopped working with the last update. They can tell me the current (non-working) build but that's about all. I whip out my work log and search for that build number. Then I dig out the source archive for the build PRIOR to that, and isolate the form/module/class that implements the diseased feature x. I can then use UltraCompare (or Eyeball Mk I) to compare the old source with the new, and hopefully spot the change(s) responsible.
If I'm lucky there might be a work log comment from past-me identifying the exact change causing the problem. Usually these things are resolved quickly once the section of changes is ID'd.
It's not perfect, but it works for me. It's simple, non-obtrusive, as comprehensive as I want to make it, and (best of all) uses off-the-shelf technology that does not require anything more than WinZip and Notepad to get at my old code. I used to use VSS but rapidly became disgusted when it "ate" my projects occasionally, got hung up on a checked-out module, or simply self destructed. This is soooo much better (for me).
I recognize this is not geared directly to revisions of graphic files or geodata, but it could be adapted easily.
HTH,
Ralf
nudone:
I'd agree with Ralf's system. i just use a typical file naming system but put comments inside a text file so that there's room to add enough explanation for what the different variations are - i know i'll forget what things are within a couple of months so i make it all as descriptive as possible.
i also use filehamster - when i think there will be plenty of revisions and i may wish to return to an old file version.
also use ACDSee to add comments to individual files - not much use outside of ACDSee but it's a quick way to see your comments directly alongside an image (or any other file you've allowed ACDSee to display).
jgpaiva:
I usually use a system that keeps it simple, fast and organized, and at the same time allows me to always work on the same filename. (note: this probably makes more sense for folders with more stuff inside than for single documents)
I work on a directory named "current". When i want to save the current state, i go one directory up, copy "current" to "copy of current", create a new folder with the current date/time and move both the "copy of current" and the other "date/time" folder inside that new one.
The advantage of this is that i only keep 2 folders at the root (the current and the last backup), and i can still quickly browse through the older copies (by double-clicking the top folder as many times as i want until i find the one i want).
Here's a folder tree of gridmove's folder:
gridmove
-20070906
--20070810
---20070705
----(etc)
----Copy of Current
---Copy of Current
--Copy of Current
-Current
The big advantages are that i can do all this in XYplorer, and all in a matter of seconds, and that i can quickly browse the tree of older revisions and choose one.
ADVISORY: using this system with something that takes a lot of space (like images) and has frequent revisions is a VERY bad idea, you'll run out of space pretty fast. For that kind of thing, a CVS/SVN or filehamster would definitelly by a better idea!
tomos:
hmmm, getting loads to think about here !! :-\
consistency, yes, absolutely mouser :)
Re current setup,
I not only keep multiple versions of files, but have very regular incremental backup going on.
Problem with incremental backup is if something gets changed & I dont notice it for a while it can be a bummer trying to find last known pre-change version or whatever.
Yes,
I guess this could be a problem with any of these solutions
(e.g if something changes without my planning or noticing or keeping record of it) -
but I know if I have comments or keep a good record a la Ralf that it would make my life easier
What would be nice in a doc ... maybe a spreadsheet would be better for me - sometimes I might have dozens of files (as opposed to versions) in a project.
What can be difficult is if i have to make (similar) minor adjustment to say 100 files
writing re each file in a doc would then be timeconsuming...
I'll have to think about possible structures
Nudone, just read your post - do you not sometime find it confusing having three different "systems"
every time i try to post there's a new post :D
jgpaiva,
will read yours now but gotta head out ..
'later! tom
nudone:
tomos, er, yes it's somewhat confusing having more than one system but they are kind of independent too.
filehamster is only used when i'm working on something, the current project. i use it just in case i need to revert back to an older version of a file - filehamster has automatically saved the different versions for me. so it's the automation thing that is the most useful to me. when designing web graphics i'll do many variations of an image - with filehamster i don't have to manually rename the file or move a previous version to another location. i just create the new image and it drops right into place in the web page design - if i change my mind about the graphic i just bring back a previous version using filehamster. no messing about renaming, etc. after i've completed the project i'll dismiss most of what filehamster what saving for me - lots of the files will be almost duplicates or too similar to bother keeping.
acdsee this is more of a reminder to what i might do with an image (or file). lots of images will have the same comment (or maybe a tag or both comment and tag). other images will have a comment that is a unique list of instructions for what needs doing to that particular graphic.
text file a project like a web site design will have plenty of things done to it that i'm sure to forget about. easy to forget how something was made to work in an awkward browser or whatever. so, i'll make a note of it all - if i used a tip from a book i'll state the book and page number - it it was a website then i might copy and paste the information and url from the site . they are all just little things to remind me of how and why something was done. and i'll also include a todo list of what needs finishing, etc, etc.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version