Re: Emacs Bazaar repository

[Thomas Lord]

Mike Mattie wrote:
> If you were going to invest your time and skills into hacking on a VCS do you
> really want to choose coding out-of-tree scripts for CVS ?
>   

The question of making short-term investments of my time
in this area has been weighing heavily on my mind, lately.
The original Arch took like 4-6 weeks to code and, now, years
later, I know a lot more.   So I'm trying to think of what I might
do in this area.

I don't think I want to make any programs that are CVS-specific
in any way  -- but I am thinking that the "dcvs" needs of a project
like Emacs can possibly be done in a way that doesn't make it
necessary to first move away from CVS.   Desirable to eventually
move away, absolutely -- but i'm not sure that good dcvs features
need to force that migration to happen right away.



> Any ideas that would retro-fit DVCS features onto archaic VCS systems
> would be more effective for Emacs in vc I think. From there you could
> at least expect a normalized API for common VCS operations and a larger
> audience for your features.
>
> It seems better to work on a better future for a modern VCS system, all things 
> equal,
> than working on arranging the flowers at CVS's funeral.
>
>   

Sure.  I'm not proposing to invest in CVS' future.   I'm suggesting
working on dvcs needs with the constraint that it's desirable to meet
dcvs needs without *forcing* a migration away from CVS (or any
other system).   It's best, to the extent possible, for dvcs features to
be independent of the vcs system used by each programmer.



> Your analysis from the Shift Selection thread is meticulous IMHO, this must be
> a floater (idea).
>
>   

The VCS stuff is, *yes* a "floater" speculative idea.   The shift-select 
stuff
is, ahem, well... as you say, thank you.


I'm sketchy about the concept of trying to muster volunteer labor.

But I'm a little bit hooked in interest on the dcvs woes here.

I'm just wondering what makes sense to try to do here.   Whether
I can mount a quick and dirty "Arch 2.0" push to any good effect.

-t




> btw, I have coded some large shell scripts regretfully. Even basic string 
> operations are
>      not simple ; hence perl. I doubt that any fancy merging tricks can emerge in sane 
>      form without writing a FOO -> bash compiler.
>
>      The auto-tools suite is essentially useful, but I doubt anyone is thrilled 
> by
>      maintaining autoconf.
>
>      even if you get daring and use co-processes to leverage an external "to 
> bash"
>      translator to feedback complex semantics into your bash core, many, 
>      if not most programs cannot read from pipes without SIGPIPE. The mmap assumption
>      is almost universal these days.
>
>      If you need any more horror stories along these lines, I will share them 
> privately :)
>
>   
> > -t
> >
> >
> >
> >
> >     
> > >   
> > >       
> >
> >