[Openmcl-devel] Backups, revision control, and taking over the world

[Alexander Repenning]

I am not a big fan of the ~backup files either (and just turned that  
off) but I do not completely agree on the SVN front. SVN certainly has  
its problems but there are some really nice clients available for OS X  
(e.g., Cornerstone http://www.zennaware.com/). It works even without a  
SVN server. You can just make a local repository and still get all the  
benefit from version control. Of course, you could do most of this  
with command line SVN built into OS X but some of these systems have  
nice interactive features. For instance, if I change a file in CCL and  
command tab to Cornerstone it already shows the the modified files and  
even a side by side diff. In that sense CCL and version control  
already feel very connected.

With version control there is not a huge need for backup files. I do  
agree, however, it would be nice to have that separate folder  
collecting backups. Perhaps these backup files would automatically be  
deleted after n days.

Alex



On Aug 5, 2009, at 2:50 PM, Ron Garret wrote:

> I wanted to change the way Hemlock stores backups.  I like having
> backups, but I don't like having them stored with the emacs convention
> of appending a twiddle to the file name.  (I'd rather have them stored
> in a hidden directory where I can get to them if I need them but they
> aren't in my face every time I look at a directory.  I'm a bit of a
> neat freak.)
>
> While wandering through the sources I found this intriguing bit of
> code in cocoa-editor.lisp:
>
> (defun write-hemlock-backup-file (url)
>   (unless (%null-ptr-p url)
>     (when (#/isFileURL url)
>       (let* ((path (#/path url)))
>         (unless (%null-ptr-p path)
>           (let* ((newpath (#/stringByAppendingString: path #@"~"))
>                  (fm (#/defaultManager ns:ns-file-manager)))
>             ;; There are all kinds of ways for this to lose.
>             ;; In order for the copy to succeed, the destination
> can't exist.
>             ;; (It might exist, but be a directory, or there could be
>             ;; permission problems ...)
>             (#/removeFileAtPath:handler: fm newpath +null-ptr+)
>             (#/copyPath:toPath:handler: fm path newpath +null-ptr
> +)))))))
>
> The reason it's intriguing is that quite a bit of effort seems to have
> been made to accept a URL as an argument, as opposed to accepting a
> file name, or simply converting the URL to a file name and calling
> COPY-FILE.  All this to me strongly hints at the possibility of using
> the IDE to edit source files that are stored in places other than the
> local file system.  Like, say, a RESTful web-based file store.  Like,
> say, a remote SVN repository.  (Well, maybe not SVN because SVN
> sucks ;-) but you can connect the dots.)
>
> I would think that having an IDE whose editor was closely coupled with
> a revision control system would be a Cool Thing (tm).  It would
> significantly reduce the barriers to working on collaborative
> projects.  Might get people's attention.  Might be the sort of thing
> that those clever folks at Clozure might have already thought of.
>
> So... is the fact that write-hemlock-backup-file takes a URL as its
> argument just a tease, or is something like this already on someone's
> agenda?
>
> rg
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel

Prof. Alexander Repenning

University of Colorado
Computer Science Department
Boulder, CO 80309-430

vCard: http://www.cs.colorado.edu/~ralex/AlexanderRepenning.vcf


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20090805/2d9b7fd4/attachment.htm>