emacs local version control - version-control

I am wondering if there is local version control/snapshots for emacs independent of VC?
let me clarify:
every time I save buffer, I would like to be able to keep track of changes of each save in session. I know I can do something similar with backup files, but they are not automated like VC and a somewhat cumbersome.
I have searched Google, but did not find the solution.
Perhaps my query string was not good.
I found this for eclipse, am looking for emacs equivalent:
http://help.eclipse.org/help32/index.jsp?topic=/org.eclipse.platform.doc.user/gettingStarted/qs-55.htm
Thanks

AFAIK there is no such solution, but you can make some ad hoc one - like creating a local VCS repository and advice the save-buffer command to commit the changes in the repository.
I also came across a section of the manual that might be of interest to you.

I don't know of a way to get Emacs to save buffer snapshots, but keep in mind that it has an infinite undo facility. If you just want a way to get back to earlier versions, that might help you. If you want real version control, then I'd go with Bozhidar Batsov's solution and advice the save-buffer command.

http://www.emacswiki.org/emacs/BackupEachSave

Related

Emacs: opening any file in a large repo

What I need
a fast/performant way to open any file under a large (git) repo (~9.8k files).
Context
I have tried various solutions, like Textmate.el and find-file-in-repository. I found these solutions via previous SO questions like this and this and through the LocateFilesAnywhere EmacsWiki.
While both solutions work wonderfully for small-to-mdeium repos, in this case they are practically unusable. When I start typing a filename, there's a delay of several seconds before I see any result. And changing any part of the search is very laggy too.
I think the main problem is that on typing any character, emacs/find-file-in-repository starts a shell command (git ls-files...). I really only need to do that when I have stopped typing.
Questions
is there a better library out there for this use-case?
if not, how can I introduce a delay into the command when I'm typing? i.e. while I'm in find-file-in-repository, I want the find-command to be invoked only when I stop typing (let's say a gap of 300ms).
Summary
After I received the three answers I tried them out (also answering my own question as none of the above solutions worked for me). I finally settled for helm-ls-git. Here's a comparison from my point-of-view:
Projectile
took around 30 minutes to index the repo. Since projectile is not aware of .gitignore, the actual number of files is more like 52k.
can be customized but something that just works (i.e. understands git) is preferable
may need to invalidate cache re-index time to time. That would be costly and frequent since new files are added everyday to the repo.
helm-cmd-t
looked good from the description and the source.
hard to install since it's not published in melpa/marmalade etc. More details in this issue I opened up.
GNU Global
Didn't try as it's likely to have the same problems as Projectile (git-unaware, needs it's own "index" that may need to be maintained time to time)
event-jr's answer however opened up some more options: I was unaware of helm till now. Looking at melpa for helm related plugins I found the following:
helm-git
This looked really promising
Was easy to install with package.el since it's in melpa
I also use and love magit - so this looked a good fit.
However, it kept failing with a magit-git-dir: symbol is void kind of error. Did not dive in too much but looks like it needs to be updated. Opened up an issue
helm-ls-git
As the readme says, this is magit independent.
Has been working wonderfully so far. Easy to install (melpa) and is fast.
I use GNU global for this. I have around 20K files in my project. You can run
M-x gtags-find-file and type first few characters. TAB will complete and show all the matching. You can type any characters which is part of the file name and press enter. Will show all the files that contains these characters.
I tried to use projectile for this. But it was way too slow for the 'project indexing'. It didn't complete the indexing even after 1.5 hours and I have to kill it!. Not sure some thing is wrong here. GNU global is much faster and finishes the entire tag creation within 15 min.
You can check out Projectile. It was basically created to provide something similar to C-p, but has a lot of extra project level features as well. First time project indexing will be fairly slow on such a big project, but afterwards Projectile will cache the project files (both on memory and on the hard drive) and subsequent projectile invocations should be nearly instantaneous.
Projectile also has a Helm plugin to display project files and buffers with Helm.
I use helm-cmd-t happily. It will cache the file list in memory. The cache controls are flexible enough for my needs.
I just answered your question about new repo address here:
https://stackoverflow.com/a/8025310/903943
It's https://github.com/lewang/helm-cmd-t

In Emacs how to prevent the same buffer from showing up in different windows in the same frame?

I'm not sure how to comprehensively accomplish this.
Currently I build my own bzr Emacs on Windows, so I can see that `display-buffer' now takes a SPECIFIERS option, which could be interesting, but I couldn't find concrete examples of how to use it.
But this problem really has to be solved before display-buffer is called.
For example a Help window previously was visiting Buffer-A, but I've visited Buffer-A in another window while reading the help. Now when I quit the Help window, Buffer-A appears there as well. I want some other useful buffer to appear there.
I have some experimental code that appears to work here.
I emphasize experimental. This could melt your Emacs.
I'd appreciate it if you could contact me on github or here to let me know your experiences with this.
Emacs 24 is not yet released. They have changed the buffer-display/window behavior and Lisp interfaces several times over the release's development period. The current status of the release is pretest, so development is supposedly stopped, except for bug fixes.
However, ongoing emacs-devel#gnu.org discussions show that things are still in flux wrt buffer display and windows.
Your best bet is to check the latest doc and code (which might not correspond exactly, at this point).

System for automatically logging exact file code changes by line item

Does anyone know of a software or system for automatically tracking and logging exact line code changes into a log file?
For example, lets say I edit 7 files on Jan 16th, and I add and modify several lines of code in each file.
Is there a software or tool of any kind that would automagically know what edits I made, what was changed, and log the details in date order line-item file?
I am guessing something exists like this, but I cannot find out what I should be searching for. I looked at SVN and some other similar, but didn't get these capabilities from the descriptions I read.
There's nothing that would automagically know this. This sort of information is easy to come by as a side-effect of using virtually any version control system though. It sounds like you're not using any VCS, you should start doing so now. SVN is a good option to start with.

Are there any apps that save backup versions of a file with one click (save, commit, etc) live while editing?

Just something that will save changes automatically, while i'm editing say in gedit, or notepad plus plus, or even windows text editor, etc.
I can't seem to find exactly what I'm looking for and svn, bzr, and Git are too complicated. One should be able to start a new project, start writing code, and that's it!
So... I'm going to create a whole new version control system that will be more amazing and simple than all the rest! Unless something already exists? Whether it be online, or a local install, whatevs.
EDIT: Ok, the above paragraph was a bit absurd now that I read it much later. I use Git now, and Git is awesome.
Many text editors will create a backup copy of the prior version when you do a save.
Of course, this is pitiful compared to an actual version control system. You should know that many VCS integrate with editors so commits are very simple quick commands.
The minor time it takes to create a repository is insignificant compared to the time it will save you during the project.
Frankly, this sounds like an argument from ignorance.
I found this nice little Gedit plugin: http://nerdblog.pl/2009/06/01/save-and-commit-to-git-plugin-for-gedit-2-26ave/

Eclipse diff for large file shows incorrect differences

I am not sure if anybody has experienced this.
I am working with a very large file having 7000 lines of code.
I made a lot of changes and when i compared the file with the repository version, it showed me incorrect differences.
I guess the diff algorithm buffers only limited number of lines ahead/behind for searching the current line, and on failing to find that, it simply shows diff with current line in new file.
One such snapshot > http://picasaweb.google.com/lh/photo/ENwZ4gqXxiCF3SWqVnVAqA?feat=directlink
If anybody knows any workaround, please let me know.
Thanks
Easy workaround - use another diff tool. I'm serious. I wouldn't waste time splitting up my files, or wondering how to get it to work with Eclipse's diff tool if there's some known issue with really big files.
I recommend Beyond Compare 3. I say this having used many different diff tools. It's not free, but it's worth it. In the rare chance that it gets confused, it allows you to with a couple of clicks realign any areas that it got confused on. I have used it with some pretty large files, and it rocks.
If you're concerned about Eclipse integration, there's even a plugin, BeyondCVS, that allows you to launch your Beyond Compare diffing from the Eclipse right click 'Compare' menus. Its name is kind of misleading though, as it doesn't appear to be related to CVS.
If you need something free, try one of these diff tools instead:
WinMerge
SourceGear DiffMerge
What version of eclipse are you using? And what edition? (Java? CDT? ...)
Depending on those data, it could make a difference, since files with several thousand lines are known to be a problem for the diff algorithm.
See this thread for illustration.
And do check, as mentioned in the same thread, your error log to check if any particular message could help you to pinpoint the cause of the failed diff.