[9fans] revision control

[9fans] revision control

[Chris Silva]

Forgive my ignorance but are there any alternatives to the CVS port? I
suppose I could use replica but that doesn't seem proper.

Thanks,

Chris

Re: [9fans] revision control

[uriel]

> Forgive my ignorance but are there any alternatives to the CVS port? I
> suppose I could use replica but that doesn't seem proper.
See yesterday(1) and history(1).

uriel

Re: [9fans] revision control

[Ronald G Minnich]

uriel@cat-v.org wrote:
>>Forgive my ignorance but are there any alternatives to the CVS port? I
>>suppose I could use replica but that doesn't seem proper.
> 
> See yesterday(1) and history(1).


These are wonderful things, don't get me wrong, but they're not really 
good enough to be an SCM.

CVS is ok.

The xen guys use mercurial now, which is written in python, and seems to 
work well. Could this python system be ported to python on plan 9?

ron

Re: [9fans] revision control

[Dan Cross]

uriel@cat-v.org wrote:
> See yesterday(1) and history(1).

As Ron said, that's not really sufficient.  You loose a lot with the
dump filesystem; log messages, branching, granularity, etc.  It's an
answer, but not a universally good one.  But, more to the point, snappy
one-liners like the above just smack of elitism and don't convey any
real information.  Just because it's not the fashionable way to do
something in the Plan 9 world doesn't mean it may not be necessary due
to circumstances beyond an individual's control.  Yeah, I've done enough
elitist bitching in my time, too, but ultimately, did anyone benefit?
Not really.

On Mon, Jan 23, 2006 at 04:18:36PM -0700, Ronald G Minnich wrote:
> CVS is ok.
> 
> The xen guys use mercurial now, which is written in python, and seems to 
> work well. Could this python system be ported to python on plan 9?

I like Subversion; it's a decent tool and has a textual on-disk
representation reminescent of RCS files.  It appears to be, ``CVS done
right.''  Sure, some things are suboptimal, but on the whole, it's
pleasant enough to work with.  But it requires the Apache runtime,
which I guess would be non-trivial to port (because it's big and
requires more patience than I have).

Personally, I'd like to see ports of unison and subversion to Plan 9.
That'd make me a happy guy.  Of course, I'd also like to have a machine
running Plan 9 again.  That'd also make me a happy guy.  Oh yeah, and
time to mess with it, too.  And time to reply to people who try and
help me out of 9fans (hi, Erik!).  Mainly, it's a time thing.

	- Dan C.

Re: [9fans] revision control

[Christopher Nielsen]

On Mon, Jan 23, 2006 at 06:37:20PM -0500, Dan Cross wrote:
> 
> I like Subversion; it's a decent tool and has a textual on-disk
> representation reminescent of RCS files.  It appears to be, ``CVS done
> right.''  Sure, some things are suboptimal, but on the whole, it's
> pleasant enough to work with.  But it requires the Apache runtime,
> which I guess would be non-trivial to port (because it's big and
> requires more patience than I have).

My last full-time tech job, I worked at the company that funds
the development of Subversion by employing the core developers.
Everyone knew I really liked Plan 9, and there was talk then
about portin the Apache Runtime to Plan 9. It didn't happen
mostly because I didn't have time; I was too busy on the ops
side to do much dev. You get Apache for free if you port APR;
I'm not sure if that's good or bad.

-- 
Christopher Nielsen
"They who can give up essential liberty for temporary
safety, deserve neither liberty nor safety." --Benjamin Franklin

Re: [9fans] revision control

[Charles Forsyth]

i think it would be possible, and might be interesting, to do a file
system type (or types) that did better what these things are trying to do.
in particular, the disadvantage of most of the systems i've used
in the past, with the exception of Clearcase, which i used only
briefly (but was largely file-system based),
is that they were neither automatic nor invisible.
furthermore, i've found the scope of most systems (again Clearcase
was an exception) to be insufficient, compared to the use
of a time machine, as hume observed many years ago.

Re: [9fans] revision control

[Skip Tavakkolian]

this gets my vote.  i've not tried cvsfs to understand the user
experience; assuming it is not limited, perhaps the internal format
could stay cvs.

> i think it would be possible, and might be interesting, to do a file
> system type (or types) that did better what these things are trying to do.
> in particular, the disadvantage of most of the systems i've used
> in the past, with the exception of Clearcase, which i used only
> briefly (but was largely file-system based),
> is that they were neither automatic nor invisible.
> furthermore, i've found the scope of most systems (again Clearcase
> was an exception) to be insufficient, compared to the use
> of a time machine, as hume observed many years ago.

Re: [9fans] revision control

[Ronald G Minnich]

Skip Tavakkolian wrote:
> this gets my vote.  i've not tried cvsfs to understand the user
> experience; assuming it is not limited, perhaps the internal format
> could stay cvs.
> 
> 
>>i think it would be possible, and might be interesting, to do a file
>>system type (or types) that did better what these things are trying to do.
>>in particular, the disadvantage of most of the systems i've used
>>in the past, with the exception of Clearcase, which i used only
>>briefly (but was largely file-system based),
>>is that they were neither automatic nor invisible.
>>furthermore, i've found the scope of most systems (again Clearcase
>>was an exception) to be insufficient, compared to the use
>>of a time machine, as hume observed many years ago.
> 
> 

Where cvs fell down for us (well, the place it was worse for us; it was 
pretty awful in so many ways ...) was that commits were not atomic. So, 
you get half way through, it fails, oh too bad, your tree is now in an 
inconsistent state. bummer.

maybe subversion code is ugly, I don't know, I just use the it. Where it 
has been useful to a number of projects is that once you commit, you get 
a simple integer back, and you can us that little number to get any 
version you want. The state of the tree is consistent at that point.

Ah well, this has turned into another low signal-to-noise ratio, full of 
pointless quotes and naughty words, discussion that seems to 
characterise 9fans from time to time.

ron

Re: [9fans] revision control

[Steve Simon]

>  i've not tried cvsfs to understand the user
> experience; assuming it is not limited, perhaps the internal format
> could stay cvs.

Not sure, but I think there may be a misunderstanding,

cvsfs creates a dump-like filesystem (with a ChangeLog) from a
network connection to a remote cvs file server, not by parsing the
repository directly.

WRT CVS, I use it at work but often wish I could move the projects to
a plan9 fileserver and use dump. As Uriel says I would want some more
tools but nothing major.

my 2¢ worth

-Steve

Re: [9fans] revision control

[Skip Tavakkolian]

in respect to cvsfs, i meant that the user interface part would remain
the same - minus the read-only aspect of the "dump-like" file system.
the internals would change so that it would mount a cvs parsing
service.  in my muddled thinking i was imagining something like upasfs
that could parse each rcs file and the cvsfs would just build a filter
for the right names for each version and serve that as an fs.

i agree about kenfs.  that's all we use here.  With several people
having a hand in the code the only person so far that has managed to
merge poorly has been me.  thankfully i can always retract my changes.

> WRT CVS, I use it at work but often wish I could move the projects to
> a plan9 fileserver and use dump. As Uriel says I would want some more
> tools but nothing major.
> 
> my 2¢ worth

Re: [9fans] revision control

[Charles Forsyth]

> i agree about kenfs.  that's all we use here.  With several people
> having a hand in the code the only person so far that has managed to
> merge poorly has been me.  thankfully i can always retract my changes.

i can believe, as others have suggested here, that just using dump/snap
alone isn't quite sufficient for some functions, and might not scale well,
especially in larger development environments.   that's why i wondered
whether another service (or services) could provide the extra support in as unobtrusive
way as the dump currently does, and with a similar all-encompassing scope.
i admit it would be hard to beat mercurial for size (and i think it's a good
example why people use python or ruby) but it hasn't the same scope
and certainty as dump.  it's actually dump's certainty that i find compensates for such
limitations (for me), but that isn't to say those limitations don't exist.

Re: [9fans] revision control

[Dave Eckhardt]

> i think it would be possible, and might be interesting, to do a file
> system type (or types) that did better what these things are trying
> to do.

One piece of work in this area is VESTA:
 http://gatekeeper.dec.com/pub/DEC/SRC/technical-notes/SRC-1999-001.pdf
 http://www.research.compaq.com/SRC/vesta

Dave Eckhardt

Re: [9fans] revision control

[Wes Kussmaul]

[-- Attachment #1: Type: text/plain, Size: 1148 bytes --]

Dave Eckhardt wrote:

>>i think it would be possible, and might be interesting, to do a file
>>system type (or types) that did better what these things are trying
>>to do.
>>    
>>
>
>One piece of work in this area is VESTA:
> http://gatekeeper.dec.com/pub/DEC/SRC/technical-notes/SRC-1999-001.pdf
> http://www.research.compaq.com/SRC/vesta
>  
>
That second url doesn't seem to work, but I found

http://www.vestasys.org/


-- 
Wes Kussmaul
CIO
The Village Group
738 Main Street
Waltham, MA 02451

781-647-7178


My uncle likes to say that the world's biggest troubles started when the serpent said, "Try this fruit, and by the way if a bunch of people collectively calling themselves Arthur Andersen signs something it's the same as if a person named Arthur Andersen signed it." I don't get the serpent and fruit part. Must be some Swiss mythology thing. He can be a bit obscure. 

                         P.K. Iggy
                         _How I Like Fixed The Internet_
                           (Tales from the Great Infodepression of 2009
                           and the prosperity that followed)



[-- Attachment #2: Type: text/html, Size: 1903 bytes --]

Re: [9fans] revision control

[Ronald G Minnich]

Dan Cross wrote:
>  But, more to the point, snappy
> one-liners like the above just smack of elitism and don't convey any
> real information.  Just because it's not the fashionable way to do
> something in the Plan 9 world doesn't mean it may not be necessary due
> to circumstances beyond an individual's control. 

yes, it's a plan 9 problem. "We don't have it, so it must not be good". 
Sometimes, it's true; not having a lot of stupid things is a plus on 
Plan 9. Other times, however, we don't have things that we ought.

Subversion is very nice. You don't really need apache, andrey has set up 
svn on xcpu.org without apache.

i have no idea of how much work it is to port, except ... it's c++, I think.

mercurial might be easier. don't know.

ron

Re: [9fans] revision control

[Charles Forsyth]

> yes, it's a plan 9 problem. "We don't have it, so it must not be good". 
> Sometimes, it's true; not having a lot of stupid things is a plus on 
> Plan 9. Other times, however, we don't have things that we ought.

oh yes, but it depends what those `things' are.  as in the exchange two years ago:

	> audio support!  i've never had audio on Plan 9, few people do ...

	That's really sad, and shows how we've lost our way.  The only reason
	there was a Plan 9 is because someone wanted a way to store and play chess
	endgames and old rock and roll.

frankly, revision control is like any other form of accountancy--worthy but dull.
audio and video?  now you're talking(!)  more strange devices! odd applications!
why can't we live a little, before it's too late and we're all absorbed into Web Services.

Re: [9fans] revision control

[andrey mirtchovski]

> audio and video?  now you're talking(!)  more strange devices! odd applications!
> why can't we live a little, before it's too late and we're all absorbed into Web Services.

we're working on it. stay tuned(!) :)

Re: [9fans] revision control

[uriel]

> Dan Cross wrote:
>>  But, more to the point, snappy
>> one-liners like the above just smack of elitism and don't convey any
>> real information.  Just because it's not the fashionable way to do
>> something in the Plan 9 world doesn't mean it may not be necessary due
>> to circumstances beyond an individual's control. 
> 
> yes, it's a plan 9 problem. "We don't have it, so it must not be good".
That is presumptuous, to say the least, some of us have had to deal
with that crap for way longer than it's healthy, and are still recovering
(ditto for all the misinformed talk that always goes around about web
browsers)

I might not be the brightest person around, but I can smell shit when
I have had to swim thru various Km of it.

> Sometimes, it's true; not having a lot of stupid things is a plus on 
> Plan 9. Other times, however, we don't have things that we ought.
Sorry, but I come from there, and I can tell you currently all VCS in
Unix are _SHIT_, with the possible exceptions of Mercurial, Darcs and
Git (in that order, mercurial is the only one I can use without being
overwhelmed with nausea, and we use it for wmii and I plan to use it
for kencc).

And I still think Plan 9 doesn't need them, maybe it needs some small
tools built around patch and yesterday/history, but even that has been
demonstrated to not be a big problem for the development of Plan 9.

Have you seen /n/sources/contrib/extra/changes?

I'm sure patch(1) could be improved a lot, but it works well enough so
far, and there are much more important things to do.


> Subversion is very nice. You don't really need apache, andrey has set up 
> svn on xcpu.org without apache.
I will quote viro:

(http://www.uwsg.indiana.edu/hypermail/linux/kernel/0210.0/2508.html)
| Damn you. That thread got me to download subversion source and read it -
| mistake I won't repeat any time soon. I've spent several months wading
| through fairly disgusting code - block device drivers are not pretty,
| ditto for devfs. I had more than once found myself grabbing Lovecraft
| to read something that would be less nightmare-inducing. But _THAT_ takes
| the fscking cake - I don't _care_ what Larry (or anybody else for that
| matter) does to people who had excreted that code. No, wait - I _do_ care.
| I want video of the... event.
| 
| I don't use BK, but you can be damn sure that I won't touch SVN. Ever. 

> i have no idea of how much work it is to port, except ... it's c++, I think.
The design and implementation of Subversion should be taught in every
engineering class, as the best example(except maybe Apache 2) of
Second System Effect abomination.

Quoting from a recent comparison of many versions control systems:
"Subversion is out of the running. [...] it's massively overengineered and
fragile, and it has as many sketchy entanglements as a submariner on a
weekend's shore leave."[1] There are similar comments all over the net for
anyone that bothers to minimally research the subject, or just go for the
source, as viro did, but you will regret it.

> mercurial might be easier. don't know.
Mercurial is probably trivial to port, 7000 lines of Python without any other
external dependencies.  (Svn is around 150.000 of convoluted C, plus 
dependencies in about every braindamaged XML/threading/DB library you
can dream of)

If you want lunix, you know where to find it; I come from spending
there a long time, and I'm certainly not going back, even if I have to
be the last Plan 9 user on earth.

And now I'm done with this thread, it's been discussed before, and
it's a waste of time to go over it again, go dig the 9fans archives if
you like.

Paraphrasing 20h's question in #plan9: how many of you, asking for a
VCS in this thread, use Plan 9 every day?

uriel

[1] http://www.serpentine.com/blog/software/mercurial.html

Re: [9fans] revision control

[Ronald G Minnich]

uriel@cat-v.org wrote:

> Paraphrasing 20h's question in #plan9: how many of you, asking for a
> VCS in this thread, use Plan 9 every day?

me.

That is a senseless question, in my view.

ron

Re: [9fans] revision control

["Nils O. Selåsdal"]

Ronald G Minnich wrote:
> Dan Cross wrote:
>>  But, more to the point, snappy
>> one-liners like the above just smack of elitism and don't convey any
>> real information.  Just because it's not the fashionable way to do
>> something in the Plan 9 world doesn't mean it may not be necessary due
>> to circumstances beyond an individual's control. 
> 
> yes, it's a plan 9 problem. "We don't have it, so it must not be good". 
> Sometimes, it's true; not having a lot of stupid things is a plus on 
> Plan 9. Other times, however, we don't have things that we ought.
> 
> Subversion is very nice. You don't really need apache, andrey has set up 
> svn on xcpu.org without apache.
> 
> i have no idea of how much work it is to port, except ... it's c++, I 
> think.
It's C. You need to port the apr/apr-util library first, most things are
built on top of those libraries.

People seem to fancy darcs too these days.

Re: [9fans] revision control

[Paul Lalonde]

On 23-Jan-06, at 3:18 PM, Ronald G Minnich wrote:
> These are wonderful things, don't get me wrong, but they're not  
> really good enough to be an SCM.
  Agreed.

> CVS is ok.
Barely.  I can't believe how difficult it is to put together a good  
revision control system.
The last couple of months were an interesting recapitulation of  
revision control for me.  Started a new job, at a startup, without an  
SCM.  CVS it was, and within the first branch/integrate cycle we were  
using Subversion.  A month later we've dropped coin on Perforce just  
for it's ability to manage branches and integrations in a sane way -  
something I haven't seen in any of the open source offerings.

The key problem is that most of the open source seem to support the  
open source development model: one person does all the integration  
into the main branch, usually re-writing the bulk of the change on  
the way through.  Integration into dev branches is rare, done only  
(it seems) at releases.  Heck, dev branches seem rare, and frequently  
seem to  be interpreted as forks rather than concurrent efforts.

Instead, at least in my work, dev branches are common: I run 2-3 at a  
time, corresponding to different bugs/features that I'm working on at  
the moment.  Integration into the main tree happens 2-3 times a week,  
integrations from the main tree daily.  The other developers do the  
same - integration *has* to work smoothly in that kind of environment.

If only subversion could understand what changes had and hadn't been  
applied to various branches.

Does anyone know an alternative to Perforce (which doesn't work so  
well disconnected) that does branching and integration so easily?

Paul

Re: [9fans] revision control

[Christopher Nielsen]

On Mon, Jan 23, 2006 at 03:42:37PM -0800, Paul Lalonde wrote:
> 
> If only subversion could understand what changes had and hadn't been  
> applied to various branches.
> 
> Does anyone know an alternative to Perforce (which doesn't work so  
> well disconnected) that does branching and integration so easily?

you might have a look at codeville http://www.codeville.org/.
i haven't used it extensively, but it tries to solve some of
the complaints you have about subversion.

-- 
Christopher Nielsen
"They who can give up essential liberty for temporary
safety, deserve neither liberty nor safety." --Benjamin Franklin

Re: [9fans] revision control

[uriel]

> uriel@cat-v.org wrote:
>>>Forgive my ignorance but are there any alternatives to the CVS port? I
>>>suppose I could use replica but that doesn't seem proper.
>> 
>> See yesterday(1) and history(1).
> 
> 
> These are wonderful things, don't get me wrong, but they're not really 
> good enough to be an SCM.
> 
> CVS is ok.
> 
> The xen guys use mercurial now, which is written in python, and seems to 
> work well. Could this python system be ported to python on plan 9?
The question is, do we need it?

I have used mercurial, and it's far better than any of the hideous alternatives in Lunix,
but I don't think Plan 9 needs it.

uriel

Re: [9fans] revision control

[FernanBolando]

[-- Attachment #1: Type: text/html, Size: 1761 bytes --]

Re: [9fans] revision control

[David Leimbach]

[-- Attachment #1: Type: text/plain, Size: 1433 bytes --]

On 1/25/06, FernanBolando@astec-power.com <FernanBolando@astec-power.com>
wrote:
>
> From: Ronald G Minnich rminnich@lanl.gov
> >Dan Cross wrote:
> >>  But, more to the point, snappy
> >> one-liners like the above just smack of elitism and don't convey any
> >> real information.  Just because it's not the fashionable way to do
> >> something in the Plan 9 world doesn't mean it may not be necessary due
> >> to circumstances beyond an individual's control.
> >
> >yes, it's a plan 9 problem. "We don't have it, so it must not be good".
> >Sometimes, it's true; not having a lot of stupid things is a plus on
> >Plan 9. Other times, however, we don't have things that we ought.
> >
> >Subversion is very nice. You don't really need apache, andrey has set up
> >svn on xcpu.org without apache.
> >
> >i have no idea of how much work it is to port, except ... it's c++, I
> think.
>
> >mercurial might be easier. don't know.
>
> In linux I use darcs it's written in haskell. I tried once or twice to
> look into
> ghc source and try to get it running under plan9 so I can run darcs but
> failed.
> I dont have much experience with haskell except for darcs.
>
> Maybe someone with more knowledge with haskell can take a look.
>
> ,Fernan
>


You are supposed to be able to generate some intermediate C to port haskell
to new platforms.  I took a swipe at this once... it did not go well :)

Dave

[-- Attachment #2: Type: text/html, Size: 3253 bytes --]

Re: [9fans] revision control

["Nils O. Selåsdal"]

FernanBolando@astec-power.com wrote:
> From: Ronald G Minnich rminnich@lanl.gov <mailto:rminnich@lanl.gov>
>  >Dan Cross wrote:
>  >>  But, more to the point, snappy
>  >> one-liners like the above just smack of elitism and don't convey any
>  >> real information.  Just because it's not the fashionable way to do
>  >> something in the Plan 9 world doesn't mean it may not be necessary due
>  >> to circumstances beyond an individual's control.
>  >
>  >yes, it's a plan 9 problem. "We don't have it, so it must not be good".
>  >Sometimes, it's true; not having a lot of stupid things is a plus on
>  >Plan 9. Other times, however, we don't have things that we ought.
>  >
>  >Subversion is very nice. You don't really need apache, andrey has set up
>  >svn on xcpu.org without apache.
>  >
>  >i have no idea of how much work it is to port, except ... it's c++, I 
> think.
> 
>  >mercurial might be easier. don't know.
> 
> In linux I use darcs it's written in haskell. I tried once or twice to 
> look into
> ghc source and try to get it running under plan9 so I can run darcs but 
> failed.
> I dont have much experience with haskell except for darcs.
>  
> Maybe someone with more knowledge with haskell can take a look.

There's an old port of hugs at
http://pages.cpsc.ucalgary.ca/~mirtchov/p9/hugs/
It might do, or not.
At any rate, hugs looks a bit friendlier to port than ghc.

Re: [9fans] revision control

[uriel]

> There's an old port of hugs at
> http://pages.cpsc.ucalgary.ca/~mirtchov/p9/hugs/
As far as I know that site might go away any moment, all the stuff
there is(or should be) in: /n/sources/contrib/andrey/

There are enough pointers all over the net to that site, please
lets not add more.

Andrey: it would be nice if you could replace the whole site with a
note pointing to sources, also I think there are some bits
(documentation in particular) that are missing from sources.

And I hope this serves of example to everyone else: Please don't put
things on random sites all over the place, use sources/contrib
instead.

uriel - tired of fixing broken links

Re: [9fans] revision control

[andrey mirtchovski]

the site has moved in its entirety to
http://www.sdgm.net/who/andrey/p9 (thanks to Dan Cross). i'll put
redirection at ucalgary once i get around to it.

i would like to extend my gratitude to uriel for fixing all the broken links.