OT: Does anyone know of a version control system that doesn't use separate files or a repo?

[isync]

I like the simplicty of a single files to note stuff down. But eventually this stuff grows and being a bit manic I want to keep track of these changes - for later perusal when I'm old and grey or so.. ;)

RCS keeps a separate file for versioning data. Git/Hg are just overkill for a single text file.

Does anyone here know of a version control system that keeps its data in the tail of files? Instead of writing somewhere else? (I am feeling just a bit guilty for posting off-topic stuff. Mh.)

[moritz]

Git/Hg are just overkill for a single text file.

Overkill by which metric? You don't need to install any server to use them, the only real downside is that you should keep the file in a separate directory.

But if you use git or hg for other projects anway, they are installed, and typing 'git init' isn't really all that much extra work, and the few additional files won't fill up your hard disc anytime soon.

[JavaFan]

the only real downside is that you should keep the file in a separate directory.

And even that isn't required.

[chromatic]

You could install OpenVMS in a virtual machine image, but if Git or Hg are overkill....

I use Git. Sure, it's a little bit of extra overhead, but I use it for large projects too, so the discipline of ubiquity pays off in what I don't have to remember to do differently.

[toolic]

I do not know of such a thing.

Version control system for the laziest of the lazy doesn't satisfy your requirement for no external files, but instead of making copies, you could just keep appending to your file.

[TomDLux]

Version Control satisfies two needs, not one. Besides keeping track of previous versions, it also provides an archive, in case your file becomes damaged or lost. Consider the consequences of an additional space:

rm * .x

Having RCS,v files in the same directory or a subdirectory is a minimal protection. Having the archives in a separate file path limits your ability to wipe out your archive at the same time you delete a file. Having them in a separate partition makes it harder for the system to destroy both original and copy at the same time. Having them on a separate machine is even better. Considering a 2 TB drive costs $65 at Newegg, you can afford to partition part of a drive as a repository.

[chrestomanci]

You could write a simple script to copy the file(s) you are working on to a safe place, and append the current data & time to the filename so they are all kept separate. You could even add that script to your cron so it runs every hour or so.

The problem with that approach is that you will end up with thousands of versions of your file, all filling up your disc, and no commit messages to tell you which one contains the edits you are looking for. Far better to create a simple hg or git repository and use that.

One situation where simple copying at frequent intervals might be useful, is if you want to get back from recent editor mistakes where there is no checked in file. On one project I worked on recently, I created a script to put all the files currently out for edit into a time stamped zip file. I had a cron job call that script every ten minutes during working hours.

I used the zip files to get back old versions of the source I was editing, if I realised that the approach to a problem I had spend the last hour on was a dead end, I could easily get back the version from an hour ago.

To be clear this was not a source code version control system, it was just a quick hack to snapshot files that where checked out for edit.

[GrandFather]

Following up on moritz's comment: Mercurial at least (I've not used Git) adds a .hg folder to the folder containing the files/folders you are managing. It's not a lot of clutter and, as suggested, isn't going to take significant space on your drive.

If you are really worried by the clutter of one extra directory entry make the parent folder the root of the repo. Mercurial at least doesn't insert any additional "In your face" entries anywhere in the directory tree. Of course if you do go up a level then you may be able to place a whole bunch of files under revision control with no extra effort.

Perhaps however none of this helps in your situation, but as we don't know what that situation is it's kinda hard to address your real problem (if we haven't already).

[ikegami]

Same for git, except it's called .git.

[ikegami]

Does anyone here know of a version control system that keeps its data in the tail of files?

I don't know what you mean by "tail of files", but it sounds like you're asking for a system that keeps the version data in the file itself?

That would be a very specialised system. The RCS would have to be familiar with the format of the file, and it could only work with file formats that have a concept of comments. It wouldn't work with a basic text file, for example.

I doubt such a system exists. It's just too complicated and limited.

[Tux]

/me mumbles SCCS. But SCCS is long dead and gone. git might be overkill, but it for sure is less hassle than SCCS.

[davies]

Many members of the MessOffice family have a "track changes" option. I hate it, but it may do what you want. I don't know about other office packages like OpenOffice.

Regards,

John Davies

[sundialsvc4]

Whether you consider “the simplicity of single files” to be long-term preferable, git probably is your best long-term solution.   You do need to be using text files, though, so that you have meaningful revision-control and differencing capability that is “obviously related to the content changes.”   Do not overlook the revision tracking capabilities that may exist in your word-processor and/or in publicly available systems such as Microsoft SharePoint.®   Your needs are not that far removed from those of ordinary document collaboration even though in this case only one person and one document are involved.

[isync]

So I had to roll my own... Comments welcome!


Read more... (5 kB)

2011-10-16T22:00:00: @GrandFather: Changed it. Thanks!
2011-10-17T18:00:00: code once again updated

[GrandFather]

I see that you have a loop to allow multiple files to be processed, but in the implicit commit code if there is no change in a file the script exits without processing any remaining files (if ($diff eq '') {print "No changes. Exiting.\n"; exit;}). Is that intended behaviour? Printing the name of the unchanged file then skipping to the next file is probably more appropriate.

[wazoox]

You could use a versioning file system, for instance NILFS (works pretty well, never failed me so far) which is included in recent Linux kernels.

[choroba]

Just for completness: no one has mentioned Subversion yet.

[chrestomanci]

No one has mentioned subversion because it is a long way from the OP's needs. isync does no want a version control system that requires the overhead of a server, or will clutter up his file-system with control files and hidden directories.

Most of the posters on this thread, have made the point that both hg and git create only one hidden control directory, have no other administrative overhead, and that the benefits outweigh the trouble.

Subversion while being a fine version control system for many purposes, does fail on both points, In any sensible set-up it requires a server that need set-up and maintenance, and it clutters up every subdirectory of your source tree with .svn directories.