I'm looking for a way to do version control on a set of files, but not for project history, more of an extended undo. Basically I'm looking for a very simply version control with little overhead that will watch a directory for changes then save the differences so I can go back and view any file at any save. I don't want all the features of git or another version control like it. Also I don't want to have to commit changes, changes should be save as soon as a file is modified. Any suggestions?
I'm contently running into situations I write a block of code, save the file, rewrite the block of code, save the file, then realize I need it like it was at first but can't undo in my text editor for some reason.
Dropbox has a very simple version control only for files. You can revert to any previous version and every time yo save changes and updates the file it creates a new version. You can work on Dropbox folder to do this automatically
Related
For some reason, whenever there's a change in a file, VsCode creates multiple copies for each change which are shown in the source control, I don't know why has that started to happen:
A vsCode extension called Local History for maintaining local history of files, when enabled, creates a copy of the old contents kept in the local history, every time you modify a file.
Disabling the extension was the solution here! :)
How do I view a particular file from a particular commit/version?
I have seen the solution where you view the file in (any) History, right-click it and select Log Selected and then choose Open Selected Version. However, this only works when I can find the file in History, which means I need to find a commit/version where the file was updated. I don't have this info.
I have also seen solutions where I can checkout the old version. However, I'd like to avoid this. I have current files open in editors and want to keep them there, unchanged. Generally, I find that checking stuff out and creating new branches sometimes creates annoying head/branch/whatever errors that I'd just as well avoid just to view a single old file.
I used to use TortoiseHG where I could right-click any version, choose to view the files in that version, get a window showing all files, and then open any file from there as a temp file.
My iPhone application uses Core Data and a SQLite database; versions are being tracked using SVN. Adding data to the database is not reflected in the application. I make sure I delete the project out of the simulator and that the new database is added as a file to the project. I suspect the data is being cached in another location.
Please note, SVN shows no changes to the database, even when directly edited. Also, if I copy and paste the project to a new folder, delete the hidden svn folders, delete the build folders, edit the DB, delete the project out of the simulator, then compile and run, it works the first time. After that, the data again is cached in some unknown location.
Any ideas where this could be?
UPDATE:
The solution to this was to exit my SVN Client (Versions). I am still unsure of how this affected updates to the DB; I wouldn't think it would block or revert any changes. I am now able to edit and save changes.
Thanks everyone for the help.
Could be more than a couple of things going wrong here. If you have the SQLite DB added to your project by reference, and if you haven't made any code changes, then when you click "Build" you won't see your changed DB resource copied over. Basically, Xcode has long-standing problems sensing when (referenced) resources have changed. Doing a clean build is your nuclear option, as depending on your compilation time, it can take quite a while. A better option is just to delete the .app bundle out of the build directory. This doesn't take as long for Xcode to reconstruct, although if you have a lot of resources, it also can take a while. The best option (the one I use) is to leave a "dummy" file at the root level of the folder included by reference (let's say it's a blank text file), and when I update a resource, I will make a change to the dummy file, undo the change, and hit Save (inside Xcode). This triggers something in Xcode to recursively go through that included directory to see if anything's changed.
All that aside, if you are modifying the DB file, and SVN is telling you that you haven't made changes to it, you have some other problem going on. Simply put, are you certain that the DB file has been added and checked in already to SVN, so SVN knows about it? And are you certain you're editing the same file you're checking in SVN?
Could it be that the database is elsewhere? Have you tried opening the database manually to see if the right records are there?
I'm using Visual Source Safe at a new job and it hasn't been too bad... then I renamed a file.
I clicked through the warning prompts not really paying attention realized that by renaming the file I lost all of my history. Is this really the case? I can't believe VSS doesn't support renaming.
I refactor lots of code and not having a renaming work properly really bites.
Thanks for the answers. I guess VSS does have renaming functionality, just not in Visual Studio. What a dealbreaker though, switching apps to rename a file in source control? :/
It's possible to do this in SourceSafe, but it requires a bit of manual intervention:
First, make sure the file you want to rename is checked in.
In SourceSafe, right-click the file and select Rename from the menu (or alternatively, simply press F2), then rename the file.
This only renames the file within SourceSafe. You will have to check out the renamed file to your working folder and then delete the original file from your working copy to complete the rename.
If you view the file's history (right-click, then Show History, or altenatively, Ctrl-H), you will see that all of its history is intact. Note, however, that SourceSafe will refer to the file by its new name in all of the history entries for the file. The actual rename is tracked at the project folder level. If you view the history of the folder that contains the renamed file, you'll see a history item indicating that the file was renamed from oldname to newname.
Addendum: A note on retrieving older versions of renamed files from history
Joe White commented on this answer that SourceSafe doesn't honor the original filename when you do a Get on an older version of a renamed file. This is true, if you are getting the older version from the File History viewer.
However, if you do a Get of an older version of your code (before the rename) from the parent folder's history viewer, SourceSafe will correctly use the original filename when it puts the files in your working folder.
The reason for this behavior goes back to the fact that SourceSafe tracks renames at the parent folder level and not at the per-file level.
It doesn't matter.
Once you've seen your SourceSafe "database" corrupted through no action of your own, SS could produce daily rainbows and unicorns, but they'd eventually morph into festering sea creatures of random bytes, unrecoverable by man.
Get away from Source Safe. It was a noble effort by Microsoft to get people into the idea of source control, but I've twice (in 2 years, same data store, 3 people working against it) seen it die an unrecoverable death.
Get into svn, tfs, anything else! Tell your higher-ups that you're playing with fire every time you check in. You may be as lucky as I was on the project before the failed one, or you could just end up... relying on your backup strategy...
VSS has a rename feature which maitains history
File > Rename (I am positive that this maitains history)
but its been a long time since I've used it
I have a file I need to move that's already under perforce. Once moved it needs some editing - update the package, etc - appropriate to its new location. Should I submit the move changespec and then reopen it for edit, or can I do this in one go? If so, what is the appropriate sequence of events?
I have done this before in one go, but depending on your build process, I recommend against it. What I generally do is this:
Move the file.
If the move needs a change in order to compile, open it for edit and make those changes.
Submit the changes, telling perforce to reopen the files for editing.
Make the changes for path, etc., that don't cause compile errors but should be updated.
Submit those changes with an appropriate description.
If you want to, however, you could just do all your changes in step (2) above. Perforce might change the flag for the new file from integrate to add, but it still remembers the source path for the file.
Edit: Better method
I realized that I often use a different method, but the idea of "moving" the file distracted me. So, I would recommend these steps instead:
Integrate the file into the new path/name, leaving the previous file there. I am assuming that this won't break your build process.
Submit the new file, checking it out again for edit after submission.
Make the required changes to the new file, and to the project so that you are using the new file.
Submit the edits for the new file.
[Optional] You might need to check through branch specs to see if you need to map the old file into the new one in any branches.
Create a changelist for deleting the old file, and submit it sometime later.
This method allows the edits to be cleanly separated from the rename/move, while never leaving the project in a state that won't compile.
Also, why wait for step 6? Sometimes, especially on bigger projects, you might want to move a file that another person is editing. Perforce will helpfully tell you this. By waiting to delete the file, you allow your coworker(s) to finish the edits and submit without needing to move their work manually. After the edits are submitted, they can be integrated into the new file, and then the old one can be safely deleted.
Submit the move change and then reopen for edit (you could use the reopen option too).
This is much more readable to the user in the change history.
Also, recent versions of Perforce do perform checks for changes to files after resolution. So, there may be complaints editing files after some resolve operations have been completed.
I would say always submit first then edit. It is much cleaner and makes it more obvious whats happening in your repository. Then simply checkout the file in the new location and make whatever changes. This also makes it much more obvious that the changes were made in the new location and to all it to work after renaming.
Yes you can. Simply reopen for edit the branched file (i.e. the new one). In P4Win, there is a context menu for this ("re-open for edit").
"Safely" is probably an important point here. Once you rename or move the file it'll get a revision number of "1" which looks like a new file to your Perforce client. Of course, admins will be able to get its prior history, but if the editing/version history of the file is important to you it's a little harder to get the older revision.
Update: Thanks to Commodore Jaeger and Greg Whitfield for enlightening comments.
This wasn't easy to track down regarding what the One True Answer is, even from Perforce support, so I figured I'd update everyone on what we found:
Perforce stores all versions of every document in its database.
If it's saving your file as type <text> or <ktext> then it stores the diffs of one file version to another and not the entire file.
If you check out a file, make no changes to it, and then re-submit, it will save as a new version with 0 diffs. This is configurable and P4 can be set up to ignore changelist items without any actual diffs. You can force this behavior by selecting "Revert unchanged files..." before you submit a changelist.
Use "Rename/Move..." to move files in P4 so it can track them. Don't copy them using Windows Explorer and then re-add them in P4.
If you use the "Rename/Move..." function from the context menu, the "new" file will show a revision number of "1" as though it were a new file.
However, since P4 saves every function performed on a file, you can actually get to any previous revision (and even recover "deleted" files) with the CLI command p4 filelog -i
If you want to get to the revision history of a moved or renamed file and you're not an admin, you can right-click and select its "Revision Graph" which shows every version of a file even when moved between branches.
According to Perforce support, easier tracking of revision history through branch or folder moves is an oft-requested feature and is in their current roadmap.
Perforce's answer: At the moment, there isn't a way to move/rename/integrate files and still maintain the exact file history.
However, if you were to choose "Integrate..." by right-clicking on the folder that you want to share, the versions of the files of the newly branched folder and underlying files will start from revision #1, but the integration history between the branched folder and underlying files and the original folder and underlying files will remain through which you can trace the revision history of the files.