I am doing some development by myself, and would like to have my code put into a RCS, and for ease I would like it to automatically commit all my changed code every night, with the option of tagging source at various times to mark good build. Any suggestions? I am using ubuntu.
+12
A:
IMO this is a misuse of revision control. You are using it for backup, not revision control.
When you commit, you should be committing logical chunks of work, that compile, with appropriate comments. Commits with none of the above at regular intervals really have nothing to do with RCS.
RedFilter
2010-08-31 12:26:33
+1. You will be doing yourself a *huge* favor if you commit logically. At the very least, you can use that history to remember what work you've done and to track down introduction of bugs.
Jefromi
2010-08-31 12:58:26
Periodic commits have a purpose too, which is to help avoid data loss. With tagging, it is simple to differentiate good builds from checkpoints.
Alex Feinman
2010-08-31 13:43:53
@Alex: I understand the intent - my point is that there are tools better suited to backup that won't pollute the repo with needless commits.
RedFilter
2010-08-31 13:53:00
I understand not polluting a repo with needless commits, but this is my repo for my software. It would be convenient to have my backups and logical commits in the same place, and tags would allow me to differentiate. The question is what tool can I use, not whether I should.
CptanPanic
2010-08-31 14:32:28
A:
I suggest to write a bash script that looks for files that have changed and comits them via RCS commandline. For scheduling the execution of that script I would use cron jobs under ubuntu. There's also a gui for managing cron jobs called gnome-schedule which you have to install first via apt.
edit:
Something which might help you: Get file modification date/time in Bash script
Simply use date -r $file +%F to get the date of $file
mherwig
2010-08-31 12:31:41
This is kind of unnecessary - with git, all you have to do is tell it to add the whole directory. If a file hasn't changed, it's a no-op. If it has, it gets staged for the commit.
Jefromi
2010-08-31 12:57:21
If you use RCS, there's usually a command line tool to check for uncommitted files, so I don't think you would have to use `date -r $file +%F`. Anyway, I totally agree with @RedFilter
David
2010-08-31 12:58:47
+2
A:
Just commit your changed code when you are done coding. It only takes a couple of seconds and that way you'll know exactly what is going on and be able to add relevant comments.
NotDan
2010-08-31 12:34:21
+2
A:
I like the idea of not using a version control system for backups. I'd stick to logical commits and - just run a cronjob at the wished time to create a patch file for example with subversion:
cd /foo/bar &&
svn diff > patch_r`svn info|grep Revision|cut -d ' ' -f 2`-`date +%Y%m%d_%H%M%S`.diff
This will result in patch files named like this: patch_r50143-20100831_153758.diff
That way you always know to which revision this patch applies without looking into it and the backups patches will be well sorted.
Btw: svn status shows all modified files..
Jan.
2010-08-31 13:45:20
A:
I ended up using subversion, and making a cronjob to commit everyday. It only commits changed files.
CptanPanic
2010-09-01 00:40:06