Hi,
I am just wondering what is the favorite approach to version control within
the Lisp comunity. I am a total newby to it (i.e. everynight zip up all my
files with name my-work-year-month-day) so I am looking for suggestions on
how to go about it.
"Rmagere" <·······@*the-mail-that-burns*.*figure-it-out*> writes:
> I am just wondering what is the favorite approach to version control
> within the Lisp comunity.
I like BitKeeper, especially if you occasionally need to synchronize
and exchange modifications among multiple hosts, but also need to be
able to operate in disconnected fashion. Mind you, this preference has
nothing to do with Lisp. I use revision control for all kinds of text
files.
--
Steven E. Harris :: ········@raytheon.com
Raytheon :: http://www.raytheon.com
In article <···············@raytheon.com>, Steven E Harris wrote:
> I like BitKeeper, especially if you occasionally need to synchronize
As yet another version control system, I've converted from CVS to
Subversion and have been very happy. Its free.
http://subversion.tigris.org
--
Kevin Rosenberg
·····@rosenberg.net
Kevin Rosenberg wrote:
> In article <···············@raytheon.com>, Steven E Harris wrote:
>
>>I like BitKeeper, especially if you occasionally need to synchronize
>
>
> As yet another version control system, I've converted from CVS to
> Subversion and have been very happy. Its free.
>
> http://subversion.tigris.org
I have been a big fan of PRCS, but the network version is "not quite
there" AFAIK.
Cheers
--
Marco
"Rmagere" <·······@*the-mail-that-burns*.*figure-it-out*> writes:
> Hi,
> I am just wondering what is the favorite approach to version control within
> the Lisp comunity. I am a total newby to it (i.e. everynight zip up all my
> files with name my-work-year-month-day) so I am looking for suggestions on
> how to go about it.
I'm using my own change-set based SCM written in Common Lisp.
Joe Marshall <···@ccs.neu.edu> writes:
> I'm using my own change-set based SCM written in Common Lisp.
Tell us more!
--
Gareth McCaughan
.sig under construc
Gareth McCaughan <················@pobox.com> writes:
> Joe Marshall <···@ccs.neu.edu> writes:
>
>> I'm using my own change-set based SCM written in Common Lisp.
>
> Tell us more!
My apologies for sounding like an advertisement, but the whole point
this project was to develop a product.
Some of you may remember that about 3 years ago I was working for a
small company called Content Integrity. We were in beta-test when the
internet bubble popped and our backers pulled our funding. Since
then, though, me and a partner have been putting in a lot of unpaid
effort to create version 2 of the product. It's working well enough
to manage its own files now, and with a bit more time should be a real
product.
The `middleware' layer is all Common Lisp. Down at the bottom, we
have a persistent CLOS layer. Objects built with the :metaclass
persistent-standard-class are durable. There is a transaction layer
on top of this to provide ACID properties. (So any modification to
CLOS objects will be undone if you abort.)
The next level up implements persistent versioned CLOS objects. When
you begin a transaction, you select a version scope and the state of
the CLOS objects is seen as per that version. The interesting thing
is when you *modify* the versioned CLOS object. At the end of the
transaction, a change-set is created to reflect the new state of the
objects. (A change set is somewhat like a delta) The change-set is a
persistent CLOS object.
Also in this layer is a mechanism for externalizing versioned CLOS
objects and change sets, so you can export and import them. (and
thus do distributed development)
On top of this layer, it is pretty easy to model anything that
changes, but the SCM market is the obvious target. You have versioned
CLOS classes for the file system and the various branches and versions
of a project and file changes are simply modifications to the
file-contents slot. There's a higher-level product management layer
on top of this that allows you to mix-and-match various versioned code
components.
I'm of the opinion that using Common Lisp is critical to this project.
(I cannot even *imagine* the hell that it would be to create a set of
versioned Java classes. There is a bit of MOP wizardry to track
changes to CLOS objects, and more to track changes to the CLOS type
hierarchy. The necessary hooks don't exist in Java. (Maybe aspectJ
could handle some of it?)) You also have to switch from context
(the versioned objects) to meta-context (the versioning control)
in some pretty complicated ways. I've added syntactic support for
this in CL, but without macros, you'd be lost.)
Joe Marshall wrote:
> Some of you may remember that about 3 years ago I was working for a
> small company called Content Integrity. We were in beta-test when the
> internet bubble popped and our backers pulled our funding. Since
> then, though, me and a partner have been putting in a lot of unpaid
> effort to create version 2 of the product. It's working well enough
> to manage its own files now, and with a bit more time should be a real
> product.
[etc]
I hope you'll announce it in c.l.l when it's done...
--
Gareth McCaughan
.sig under construc
Hmm. Well, please also consider arch:
http://www.gnu.org/software/gnu-arch
as an alternative to CVS and Subversion and (especially) BitKeeper.
At its core, like those other systems, it is line-oriented when it
comes to diffing and patching (hence merging). That's arguably less
than optimal for lisp.
Lisp is pretty interesting from a revision control perspective
because:
1) textual diffing/patching is interesting because it _approximates_
semantically robust code transforms pretty well, especially in
languages with a C-like syntax.
2) /perhaps/ in lisp, the space of code transformations that might
otherwise be captured by diff-ishness and applied by patch-ishness
can be more precisely expressed.
Kind of an area for research.....
-t
····@emf.emf.net (Tom Lord) wrote in message news:<··············@corp.supernews.com>...
> At its core, like those other systems, it is line-oriented when it
> comes to diffing and patching (hence merging). That's arguably less
> than optimal for lisp.
>
> Lisp is pretty interesting from a revision control perspective
> because:
>
> 1) textual diffing/patching is interesting because it _approximates_
> semantically robust code transforms pretty well, especially in
> languages with a C-like syntax.
>
> 2) /perhaps/ in lisp, the space of code transformations that might
> otherwise be captured by diff-ishness and applied by patch-ishness
> can be more precisely expressed.
>
> Kind of an area for research.....
On this topic, some Lispers may find it interesting to look at darcs,
http://www.abridgegame.org/darcs/.
The first paragraph of the Introduction of the Theory of Patches,
http://www.abridgegame.org/darcs/manual/node7.html
"A patch describes a change to the tree. It could be either a
primitive patch (such as a file add/remove, a directory rename, or a
hunk replacement within a file), or a compostive patch describing many
such changes. Every patch type must satisfy the conditions described
in this appendix. The theory of patches is independent of the data
which the patches manipulate, which is what makes it both powerful and
useful, as it provides a framework upon which one can build a revision
control system in a sane manner."
"Tom Lord" <····@emf.emf.net> wrote in message
···················@corp.supernews.com...
>
> Hmm. Well, please also consider arch:
>
> http://www.gnu.org/software/gnu-arch
>
> as an alternative to CVS and Subversion and (especially) BitKeeper.
>
> At its core, like those other systems, it is line-oriented when it
> comes to diffing and patching (hence merging). That's arguably less
> than optimal for lisp.
>
> Lisp is pretty interesting from a revision control perspective
> because:
>
> 1) textual diffing/patching is interesting because it _approximates_
> semantically robust code transforms pretty well, especially in
> languages with a C-like syntax.
>
> 2) /perhaps/ in lisp, the space of code transformations that might
> otherwise be captured by diff-ishness and applied by patch-ishness
> can be more precisely expressed.
>
> Kind of an area for research.....
I think that a natural way to represent a change in lisp code is by a
parse-tree operation - either a node substitution or node deletion or
insertion. Is that everything?
So the structure stored in the versioning system would be a parse-tree and
lisp-diffs would be lists(!) of parse-tree-operations, whose parameters
(where necessary) would be lisp forms.
Does this make sense?
alex
"Alex Tibbles" <············@yahoo.co.uk> writes:
> I think that a natural way to represent a change in lisp code is by a
> parse-tree operation - either a node substitution or node deletion or
> insertion. Is that everything?
Node migration. If someone wraps an unwind-protect around some piece
of code, you'd like the encapsulated code to retain its identity.
Node renaming. If someone changes all occurrances of FOO to BAR, you'd
like that not to appear as a wholesale code replacement.
"Alex Tibbles" <············@yahoo.co.uk> writes:
> "Tom Lord" <····@emf.emf.net> wrote in message
> ···················@corp.supernews.com...
> > [...]
> > Lisp is pretty interesting from a revision control perspective
> > because:
> >
> > 1) textual diffing/patching is interesting because it _approximates_
> > semantically robust code transforms pretty well, especially in
> > languages with a C-like syntax.
> >
> > 2) /perhaps/ in lisp, the space of code transformations that might
> > otherwise be captured by diff-ishness and applied by patch-ishness
> > can be more precisely expressed.
> >
> > Kind of an area for research.....
>
> I think that a natural way to represent a change in lisp code is by a
> parse-tree operation - either a node substitution or node deletion or
> insertion. Is that everything?
> So the structure stored in the versioning system would be a parse-tree and
> lisp-diffs would be lists(!) of parse-tree-operations, whose parameters
> (where necessary) would be lisp forms.
>
> Does this make sense?
Yes, but it's much more complex. CVS works on text files, that is, in
one dimension (the sequence of characters), while an algorithm on a
tree would work in two dimensions (depth and breadth). You could want
to be smarter and that would lead to works in three dimensions that
would be completely unmanageable.
After all, just applying a few syntactic transformations, a sexp could
end transmogrified in another source file. Do you want to trace it
and be able to "compress" the differences just saying that I factored
out that sexp and encapsulated in another package? Why not, that's
what I did, and these actions would even be explicit if I was using a
syntax tree editor rather than a text editor.
However there are very good ergonomic reasons why we're still using
TEXT editors, and why cvs/diff/patch are rather the right thing.
--
__Pascal_Bourguignon__
http://www.informatimago.com/
Do not adjust your mind, there is a fault in reality.
Tom Lord wrote:
> Hmm. Well, please also consider arch:
>
> http://www.gnu.org/software/gnu-arch
>
> as an alternative to CVS and Subversion and (especially) BitKeeper.
>
> At its core, like those other systems, it is line-oriented when it
> comes to diffing and patching (hence merging).
Why is it "line oriented"? Aren't the core diff algorithms purely
"string" based?
Cheers
marco
Tom Lord wrote:
{
Hmm. Well, please also consider arch:
http://www.gnu.org/software/gnu-arch
[Really, it's good. Hope folks check it out. Not exactly smack-dab
on topic for c.l.l., in and of itself.]
At its core, like those other systems, it is line-oriented when it
comes to diffing and patching (hence merging).
}
Marco Antoniotti asked:
{
Why is it "line oriented"? Aren't the core diff algorithms purely
"string" based?
}
Uh... yes?
The unix program diff(1), which "morally" if not literally is one of
the cornerstones of all of the popular revision control systems, sees
a text file as a sequence of lines, each a string.
diff(1) will tell you something like "file A turns into file B by
deleting lines 42-69 and inserting the following replacement".
It doesn't say anything like "replace characters 2352...9876 of the
file by this replacement" -- it's line oriented.
As other people in the thread have noted, the ease with which s-exp
syntax can be manipulated suggests the vague possibility of a
diff-like program that tells you things like "file A turns into file B
by globally replacing such-and-such expression with this other
expression".
There are two notable (in this context) uses for "diffing" and
"patching" (in the broadest possible sense of those words) in revision
control systems. One use is compression: by storing only the
differences between revisions, I can save considerable space compared
to storing full copies of both revisions. Another use is _merging_:
Abstractly, merging is about changing files "by analogy": you and I
start with identical copies of file FOO. We both make our personal
changes to this file and wind up with variants FOO-YOURS and FOO-MINE.
Now, you start with FOO-YOURS and make yet another variation:
FOO-YOURS-2. I would like to make analogous changes to those between
YOURS and YOURS-2 to FOO-MINE (while ignoreing the changes from FOO to
FOO-YOURS).
If these files are source code, usually the "change" has some very
high-level meaning: e.g., adding a new parameter to a function and
installing a default value for that parameter in all callers.
But diff(1), of course, sees a very low-level change: lines
such-and-such were replaced by so-and-so.
It's a pleasant and useful coincidence[1] that, especially in C-like
languages (syntacticly), very often the low-level view of a change is
operationally a decent approximate expression of the high-level view
of the change. diff(1) is "easy" to implement with high precision.
It doesn't _really_ understand code transformations. But it's a good
enough approximation that we can usually pretend that it does.
As Darius observed (or quoted from Darcs documentation): the "logic"
of revision control -- how you manage and make use of a collection of
"changes" -- is largely independent of what you mean by "change". A
few (very weak) algebraic properties for operations defined on
"changes" (whatever those are) are enough to start implementing
revision control (and features like branching and merging). The job
of a revision control system is roughly to catalog and manipulate
"changes" -- the details of what constitutes a "change" barely matter.
So, there's a potential direction for fundamental research[2]: coming
up with alternative definitions for "changes" besides "what diff(1)
says".
Lisp-family's syntactic and semantic regularities are tantalizing for
that research, becuase it's not to hard to imagine some fancy ways to
describe "changes".
Happy to say more than you wanted to know :-)
-t
[1] coincidence that diff(1) approximates code transforms
Not really much of a coincidence, I think -- but kind of
mystical. Math is universal and things with similar mathematical
models have similar properties. Yadda yadda yadda.
[2] better than diff(1) "changes" is an area of "fundamental research"
I distinguish "fundamental" from "practical" research roughly by
probabilities of positive results. "Practical research" is where
you have a good hunch that you can really do something, and the
issue is that the economics of doing it are no less difficult to
work out than actually doing it. "Fundamental research" is where
you have no idea whether or not you can do something -- and you
want to explore how to, if you can, or why you can't, if you can't.
Something like that, anyway.
From: Andreas Hinze
Subject: Re: Lisp and Version Control
Date:
Message-ID: <3F81649F.2F04FA2@smi.de>
Tom Lord wrote:
>
> Marco Antoniotti asked:
> {
> Why is it "line oriented"? Aren't the core diff algorithms purely
> "string" based?
> }
>
> Uh... yes?
>
Yes. But this is not a string of chars but a string of arbitrary symbols.
In diff it is simple a string of lines. You may have a look into the base
algorithm as described in
Eugene W. Myers
"An O(ND) Difference Algorithm and its Variations"
(available from his home page: www.cs.arizona.edu/people/gene/)
Regards
AHz
Gareth McCaughan <················@pobox.com> writes:
> Joe Marshall wrote:
>
>> Some of you may remember that about 3 years ago I was working for a
>> small company called Content Integrity. We were in beta-test when the
>> internet bubble popped and our backers pulled our funding. Since
>> then, though, me and a partner have been putting in a lot of unpaid
>> effort to create version 2 of the product. It's working well enough
>> to manage its own files now, and with a bit more time should be a real
>> product.
> [etc]
>
> I hope you'll announce it in c.l.l when it's done...
But of course!
(incidentally, we're seeking development partners)
Joe Marshall writes:
> My apologies for sounding like an advertisement, but the whole point
> this project was to develop a product.
[...]
> effort to create version 2 of the product. It's working well enough
> to manage its own files now, and with a bit more time should be a real
> product.
When it becomes a product, please consider adding an entry to the
industrial applications (or maybe success stories :) of Lisp page at:
http://alu.cliki.net
Paolo
--
Paolo Amoroso <·······@mclink.it>
According to Rmagere <·······@*the-mail-that-burns*.*figure-it-out*>:
> I am just wondering what is the favorite approach to version control within
> the Lisp comunity. I am a total newby to it (i.e. everynight zip up all my
> files with name my-work-year-month-day) so I am looking for suggestions on
> how to go about it.
CVS is fine.
I have the habit of starting up pristine images and then loading all the
stuff that I want into them.
I think startup will be faster if I save/load custom images, but I use,
well, play with CMUCL, SBCL, LWW and sometimes CLISP so keeping all these
straight is a bit too much for me.
I sometimes wonder if the Smalltalk no-files-just-the-image way suits me
better.
--
Ng Pheng Siong <····@netmemetic.com>
http://firewall.rulemaker.net -+- Manage Your Firewall Rulebase Changes
http://sandbox.rulemaker.net/ngps -+- Open Source Python Crypto & SSL
····@netmemetic.com (Ng Pheng Siong) writes:
> According to Rmagere <·······@*the-mail-that-burns*.*figure-it-out*>:
> > I am just wondering what is the favorite approach to version control within
> > the Lisp comunity. I am a total newby to it (i.e. everynight zip up all my
> > files with name my-work-year-month-day) so I am looking for suggestions on
> > how to go about it.
>
> CVS is fine.
>
> I have the habit of starting up pristine images and then loading all the
> stuff that I want into them.
>
> I think startup will be faster if I save/load custom images, but I use,
> well, play with CMUCL, SBCL, LWW and sometimes CLISP so keeping all these
> straight is a bit too much for me.
>
> I sometimes wonder if the Smalltalk no-files-just-the-image way suits me
> better.
Or if you want it more lispy, you could yse mcvs, which encapsulate
cvs with a more intelligent lisp layer (like cvs encapsulated rcs).
--
__Pascal_Bourguignon__
http://www.informatimago.com/
Do not adjust your mind, there is a fault in reality.
····@netmemetic.com (Ng Pheng Siong) writes:
> According to Rmagere <·······@*the-mail-that-burns*.*figure-it-out*>:
> > I am just wondering what is the favorite approach to version control within
> > the Lisp comunity. I am a total newby to it (i.e. everynight zip up all my
> > files with name my-work-year-month-day) so I am looking for suggestions on
> > how to go about it.
>
> CVS is fine.
Does anybody have a good idiom to convert the revision string into a
list (presumably at compile time)? I'm using this, but it's not very
elegant:
(defparameter *version*
(let* ((vs "$Revision: 1.8 $") minor)
(multiple-value-bind (major pos)
(parse-integer vs :start 11 :junk-allowed t)
(setf minor (parse-integer vs :start (1+ pos) :junk-allowed t))
(list major minor))))
*version*
(1 8)
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
On Thu, 2 Oct 2003 15:32:01 +0100, "Rmagere"
<·······@*the-mail-that-burns*.*figure-it-out*> wrote:
>I am just wondering what is the favorite approach to version control within
>the Lisp comunity. I am a total newby to it (i.e. everynight zip up all my
>files with name my-work-year-month-day) so I am looking for suggestions on
>how to go about it.
We use a combination of CVS for version control and Bugzilla for bug
and enhancement tracking. We've written some code in-house to
cross-link the two systems in a simple manner so that CVS check-in
messages will be recorded against the apprpriate Bugzilla bug /
enhancement reports.
The CVS repository is backed-up as part of a general server backup
procedure.
Mark
"Rmagere" <·······@*the-mail-that-burns*.*figure-it-out*> writes:
> Hi,
> I am just wondering what is the favorite approach to version control
> within the Lisp comunity. I am a total newby to it (i.e. everynight
> zip up all my files with name my-work-year-month-day) so I am
> looking for suggestions on how to go about it.
I don't know that anyone in the Lisp community but me uses it but the
p4 product from Perforce Software (<http://www.perforce.com> is quite
good. You can download their server and client and run it for free
with two users. Or if you are doing free software development, they
will give you a license to do that. Otherwise it's X bucks per seat
where X may be in the few hundred dollar range. We used it at the last
two companies I worked at it and it was great. (It's similar in
concept to CVS except it's faster and provides atomic checkins. It
also has quite good facilities for extracting historical information
since all the meta data is stored in a built-in database.)
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Peter Seibel <·····@javamonkey.com> wrote in message news:<··············@javamonkey.com>...
> "Rmagere" <·······@*the-mail-that-burns*.*figure-it-out*> writes:
>
> > Hi,
>
> > I am just wondering what is the favorite approach to version control
> > within the Lisp comunity. I am a total newby to it (i.e. everynight
> > zip up all my files with name my-work-year-month-day) so I am
> > looking for suggestions on how to go about it.
>
> I don't know that anyone in the Lisp community but me uses it but the
> p4 product from Perforce Software (<http://www.perforce.com> is quite
> good. You can download their server and client and run it for free
> with two users...
We use Perforce too. I can highly recommend it.
I have started work on a LispWorks port to P4COM, to allow p4
operations direct from the LispWorks IDE. I've only implemented "edit"
and "submit" so far, as I'm a bit busy right now, but I hope to take
it further at some point soon. If anyone would like to play with it,
please get in touch.
http://public.perforce.com/guest/robert_cowham/perforce/API/p4com/main/index.html
> ...It's similar in
> concept to CVS except it's faster and provides atomic checkins...
Branching is different ("inter-file" rather than "intra-file").
http://www.perforce.com/perforce/branch.html
- nick
Nick Levine wrote:
[someone else said about Perforce:]
>> ...It's similar in
>> concept to CVS except it's faster and provides atomic checkins...
>
> Branching is different ("inter-file" rather than "intra-file").
>
> http://www.perforce.com/perforce/branch.html
Subversion, which was also mentioned above, has a
similar approach to branching. I think it was inspired
by Perforce, not an independent invention.
--
Gareth McCaughan
.sig under construc
Rmagere <·······@*the-mail-that-burns*.*figure-it-out*> wrote:
>
>I am just wondering what is the favorite approach to version control within
>the Lisp comunity. I am a total newby to it (i.e. everynight zip up all my
>files with name my-work-year-month-day) so I am looking for suggestions on
>how to go about it.
I use CVS for all my stuff (Lisp, Perl, LaTeX, ...). Has its problems,
but works fine and its more or less the default version control tool in
the Opensource world. One of the nice things of a good version control
system is clean distributed work: you can have several people working on
the project without making a mess of the files. Another is disconnected
work: check out a working area onto the laptop, hack on it while away
from your systems, check in your changes when you are back.
Gives you change comments and diffs between versions for free too.
Another that looks promising is Subversion, one of those days I'll to
play with it for a while.
Regards,
Alex.
--
"Opportunity is missed by most people because it is dressed in overalls and
looks like work." -- Thomas A. Edison
Thanks for all the reply from which I gather that people tend to use:
CVS --> the standard (kind of)
MCVS --> more lispy
Subversion
BitKeeper
p4 from Perforce Software http://www.perforce.com/ (faster than CVS + atomic
checkins + historical informations)
Arch: http://www.gnu.org/software/gnu-arch
Now is just a matter of playing around with them and make my mind up.
Thanks again.