unofficial mirror of help-gnu-emacs@gnu.org
 help / color / mirror / Atom feed
From: Timothy Hobbs <tim.thelion@gmail.com>
To: EMACS list <help-gnu-emacs@gnu.org>
Subject: Re: Automatic versioning
Date: Fri, 04 Apr 2008 21:21:15 -0700	[thread overview]
Message-ID: <m3bq4px77o.fsf@xo-10-E6-7E.localdomain> (raw)
In-Reply-To: <200804050000.m3500NQ5004365@localhost.localdomain> (Xavier Maillard's message of "Sat\, 5 Apr 2008 02\:00\:23 +0200")

Xavier Maillard <xma@gnu.org> writes:
>
> Another solution would be to "embed" some sort of the mechanism
> from a modern DVC like GNU Bazaar or Git. Given the fact that
> they have been "libitized" (you can take advantage of them by
> linking your program against them), this should be quite easy to
> implement.

I am a bit cautious of any system with a hierarchical 'bottom' to it.  Git,
Bazaar, CVS, SVN all have these nasty things called repositories which have to
be kept track of.  Do you make / the repository?  Clearly not, you would then
have to give user write perms to it.  Do you make ~/ the repository?  Clearly
not,then etc files wouldn't be versioned in the same system.  I think RCS is
much better from this standpoint, but I'm not sure exactly how to implement
things with RCS.

VC would be great if instead of having that funky C-x v v ring for locking, and
checking in files, files where locked with an after find-file hook, and checked
in with a pre-save hook, given that there was some way to pragmatically skip
the comments prompt(which I always leave blank anyways).

Then there would be two more functions to write.

vc-prev bound to something very convenient like C-<left>

and

vc-next C-<right>

vc-prev would call a cleaned up version of vc-version-other-window which didn't
create the temp files, and of course went to the previous version, instead of
prompting.  vc-prev/next could be even better if they split the frame into 3
windows vertically:

1) Showing the diff between the selected(as it the one cycled to with
vc-next/prev) version and the one before it.

2) Showing the selected version.

3) Showing the diff between the selected version and the latest one.

This would make the whole thing slightly better than media-wiki, because that
3rd diff<the on showing changes in the latest> would be quite use full.

I tried to implement this today, but I ran into significant hurdles.

1) vc's C-x v v is quite a complex bit of functionality, and I wasn't able to
figure out what the basic back-end functions for locking and checking in where.
There is vc-rcs-checkout and vc-rcs-checkin but I wasn't able to figure out how
to use these in the find-file hook and the save buffer defadvice.

2) vc-version-other-window creates those nasty little .~version-number~ temp
files and doesn't clean up after itself.

3) I couldn't figure out how to get the version before "version" or the version
after "version".

So basically all of my prospecting of the vc api failed.

I hope there is someone out there who is more competent with vc than I who is
willing to give me guidance.  I plan to publish this work, so one special
consideration is that I don't walk over those who use vc for svn/cvs ect. I
think that once this is made everyone will realise that seamless versioning in
all files(like a very long term, visual undo)(as well as a method of seeing how
your work progressed/evolved) is not just the way to go, but something that in a
few months people will wonder how they lived without.

Wish me luck, and give me help!  Please.

Timothy Hobbs




  reply	other threads:[~2008-04-05  4:21 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-28  7:30 My dream work log: Albert
2008-03-28 16:50 ` B. T. Raven
2008-03-29 17:18   ` Mike Treseler
2008-03-30 17:21     ` Choosing a versioning system (was My dream work log:) rustom
2008-03-30 17:50       ` Choosing a versioning system Thierry Volpiatto
2008-03-30 18:32       ` Choosing a versioning system (was My dream work log:) Mike Treseler
2008-03-31 19:06         ` Choosing a versioning system Joel J. Adamson
     [not found]         ` <mailman.9728.1206990435.18990.help-gnu-emacs@gnu.org>
2008-03-31 20:24           ` Mike Treseler
2008-03-30 18:59       ` Choosing a versioning system (was My dream work log:) Oleg Katsitadze
     [not found]       ` <mailman.9661.1206909269.18990.help-gnu-emacs@gnu.org>
2008-03-31  3:55         ` rustom
2008-03-31  6:38           ` Choosing a versioning system Thierry Volpiatto
2008-03-31 21:06             ` Mike Mattie
2008-04-03 18:25               ` Nikolaj Schumacher
2008-04-03 18:51                 ` Thierry Volpiatto
2008-04-04 16:41                   ` Nikolaj Schumacher
2008-04-04 17:46                     ` Thierry Volpiatto
2008-03-31  8:22       ` Tim X
2008-03-31 22:23         ` Timothy Hobbs
2008-04-01 15:37           ` Automatic versioning (was: Choosing a versioning system) Joel J. Adamson
2008-04-01 20:48             ` Automatic versioning Timothy Hobbs
2008-04-02 13:39               ` Joel J. Adamson
2008-04-03  2:00               ` Kevin Rodgers
2008-04-03  5:22                 ` Timothy Hobbs
2008-04-04 12:24                   ` Kevin Rodgers
2008-04-04 13:44                     ` Joel J. Adamson
2008-04-04 20:35                     ` Timothy Hobbs
2008-04-05  0:00                       ` Xavier Maillard
2008-04-05  4:21                         ` Timothy Hobbs [this message]
2008-04-03 14:18                 ` Joel J. Adamson
2008-04-04 12:28                   ` Kevin Rodgers
2008-03-31 19:04       ` Choosing a versioning system Joel J. Adamson
2008-03-28 17:03 ` My dream work log: Thierry Volpiatto
     [not found] ` <mailman.9546.1206722977.18990.help-gnu-emacs@gnu.org>
2008-03-29  8:36   ` Albert

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m3bq4px77o.fsf@xo-10-E6-7E.localdomain \
    --to=tim.thelion@gmail.com \
    --cc=help-gnu-emacs@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).