Ready to start serious work on VC mode again

Ready to start serious work on VC mode again

[Eric S. Raymond]

Cleaning up Battle For Wesnoth for the big stable 1.4 release, and
dealing with the aftermath, took longer and ate more of my bandswidth
than expected.  But I'm ready to restart serious work on VC now.

Rumor reached me that RMS chose bzr for our next version control
system while I was gone.  While I think the essentially political
("it's a GNU project") reasoning I heard of behind this was a very poor
way to make that sort of decision, I can live with it.  I suspect
either hg or git wiould have mmade a better technical choice, but it's
not as though bzr actively sucks...

What effort, if any, is being put into migrating the CVS version
history?  I'd be willing to help with that.

What's the state of play on deploying an issue tracker?

I have Dan Nicolaeacu's VC todo list; there are several entries I
think I can knock off pretty quickly.  Big props to Dan for his
excellent work.

Are there any know, urgent VC bugs I should address first?
--
						>>esr>>

Re: Ready to start serious work on VC mode again

[Jason Earl]

"Eric S. Raymond" <esr@snark.thyrsus.com> writes:

> Cleaning up Battle For Wesnoth for the big stable 1.4 release, and
> dealing with the aftermath, took longer and ate more of my bandswidth
> than expected.  But I'm ready to restart serious work on VC now.

I've been meaning to take another look at that game...

> Rumor reached me that RMS chose bzr for our next version control
> system while I was gone.  While I think the essentially political
> ("it's a GNU project") reasoning I heard of behind this was a very
> poor way to make that sort of decision, I can live with it.  I suspect
> either hg or git wiould have mmade a better technical choice, but it's
> not as though bzr actively sucks...

Clearly you haven't used bzr on a project with over 80,000 revisions :).
Importing the Emacs repository into bzr has certainly highlighted some
of the problems with bzr.

I'm only saying this because I don't particularly want to see another
flamewar about how slow bzr log is.

Seriously, the Bazaar guys are working on it already.

> What effort, if any, is being put into migrating the CVS version
> history?  I'd be willing to help with that.

An initial migration of the CVS repository using cvsps has been done.
You can find the results at:

http://bzr.notengoamigos.org

I would strongly recommend that you follow the instructions on that page
and get a pre-made repository.  Of course, I wrote the instructions so I
am almost certainly biased :).

I would also suggest that you get an up to date version of bzr.  The
Bazaar hackers have released a major update about once a month for some
time now with all of these updates making fairly major improvements.  It
is entirely possible that the bzr client that ships with whatever
distribution your using is old enough that it won't even read the format
that the test repository is in.

The current stable version is 1.3.1, but 1.4 is going to be released
imminently, and I believe that it will contain several fixes prompted by
the Emacs test of bzr.  If you are serious about playing with Emacs and
bzr you probably should just check out bzr.dev and use that :).

I am currently working on an entirely different import using some of the
work that has already been done in various git repositories.

> What's the state of play on deploying an issue tracker?
>
> I have Dan Nicolaeacu's VC todo list; there are several entries I
> think I can knock off pretty quickly.  Big props to Dan for his
> excellent work.
>
> Are there any know, urgent VC bugs I should address first?

I have no ideas about the rest of this :).

Jason

Re: Ready to start serious work on VC mode again

[Eric S. Raymond]

Jason Earl <jearl@xmission.com>:
> "Eric S. Raymond" <esr@snark.thyrsus.com> writes:
> 
> > Cleaning up Battle For Wesnoth for the big stable 1.4 release, and
> > dealing with the aftermath, took longer and ate more of my bandswidth
> > than expected.  But I'm ready to restart serious work on VC now.
> 
> I've been meaning to take another look at that game...

Yeah, it's why I disappeared for four months.  But the good news is
that it's our best release ever, not just for features but for low bug
load and stability too (we sweated blood to do it, but we reduced the bug
count by a factor of 5).  And it has an entire new campaign in it that
I wrote: The Hammer of Thursagan.
 
> An initial migration of the CVS repository using cvsps has been done.
> You can find the results at:
> 
> http://bzr.notengoamigos.org

Are changes made to this repo being propagated into CVS?

> I would also suggest that you get an up to date version of bzr.  The
> Bazaar hackers have released a major update about once a month for some
> time now with all of these updates making fairly major improvements.  It
> is entirely possible that the bzr client that ships with whatever
> distribution your using is old enough that it won't even read the format
> that the test repository is in.

I have 1.3.1, that's what Hardy Heron ships.  Is that new enough?

> The current stable version is 1.3.1, but 1.4 is going to be released
> imminently, and I believe that it will contain several fixes prompted by
> the Emacs test of bzr.  If you are serious about playing with Emacs and
> bzr you probably should just check out bzr.dev and use that :).

How soon is "imminent"?  If it's like, within two weeks I'll just wait.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Ready to start serious work on VC mode again

[Jason Earl]

"Eric S. Raymond" <esr@thyrsus.com> writes:

> Jason Earl <jearl@xmission.com>:
>> "Eric S. Raymond" <esr@snark.thyrsus.com> writes:
>> 
>> > Cleaning up Battle For Wesnoth for the big stable 1.4 release, and
>> > dealing with the aftermath, took longer and ate more of my bandswidth
>> > than expected.  But I'm ready to restart serious work on VC now.
>> 
>> I've been meaning to take another look at that game...
>
> Yeah, it's why I disappeared for four months.  But the good news is
> that it's our best release ever, not just for features but for low bug
> load and stability too (we sweated blood to do it, but we reduced the bug
> count by a factor of 5).  And it has an entire new campaign in it that
> I wrote: The Hammer of Thursagan.

I really do deserve a break...

>> An initial migration of the CVS repository using cvsps has been done.
>> You can find the results at:
>> 
>> http://bzr.notengoamigos.org
>
> Are changes made to this repo being propagated into CVS?

No, changes made in CVS are being propagated to this bzr repo on an
hourly basis, but it is not bi-directional.

Stefan just sent me an email that reminded me that I also should point
out that this particular repository is more of a proof of concept than a
finished product.  It's fine for testing bzr, but it is missing
important merge data that would be necessary for a proper conversion.
There are also problems with some of the tags.

I am currently working on another conversion from Andreas Schwab's git
repository at:

git://repo.or.cz/emacs.git

Apparently this git repository has a bunch of merge data that was
basically added by hand.

I will probably also see if a conversion via cvs2svn gives a better
result, mostly because I like watching top go on the server I am using
to do conversions.

>> I would also suggest that you get an up to date version of bzr.  The
>> Bazaar hackers have released a major update about once a month for
>> some time now with all of these updates making fairly major
>> improvements.  It is entirely possible that the bzr client that ships
>> with whatever distribution your using is old enough that it won't
>> even read the format that the test repository is in.
>
> I have 1.3.1, that's what Hardy Heron ships.  Is that new enough?

I am pretty sure that would still be missing a big improvement to bzr
diff -r ancestor that Stefan reported made a huge difference in his
ability to use bzr for Emacs development.  It's certainly better than
the completely unusable 0.11 version that is in Debian stable.

1.3.1 will certainly work.  Just don't come back and tell the list bzr
is ridiculously slow at some history-based commands.  We know that
already :).  Newer versions are significantly better, but there still is
some work to be done.

>> The current stable version is 1.3.1, but 1.4 is going to be released
>> imminently, and I believe that it will contain several fixes prompted
>> by the Emacs test of bzr.  If you are serious about playing with
>> Emacs and bzr you probably should just check out bzr.dev and use that
>> :).
>
> How soon is "imminent"?  If it's like, within two weeks I'll just
> wait.

I actually was surprised when I went to http://bazaar-vcs.org/ and 1.4
wasn't released.  I don't read the bzr mailing list in its entirety, but
I really thought that it had already been released.  bzr.dev currently
says that it is 1.5+.

Honestly, 1.3.1 is probably more than good enough if you are just going
to be poking around.  Especially considering that the repo in question
is little more than a proof of concept.

Jason

Re: Ready to start serious work on VC mode again

[Andreas Schwab]

Jason Earl <jearl@xmission.com> writes:

> I will probably also see if a conversion via cvs2svn gives a better
> result, mostly because I like watching top go on the server I am using
> to do conversions.

See <git://repo.or.cz/emacs/cvs2svn.git> for an (oldish) import via
cvs2svn.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Ready to start serious work on VC mode again

[Stephen J. Turnbull]

Jason Earl writes:

 > Honestly, 1.3.1 is probably more than good enough if you are just going
 > to be poking around.

But it's definitely not good enough if you're going to be doing work
on importing the whole history in appropriate ways.

Just bit the bullet and go to the bleeding edge, Eric.  It's not like
you've never been there before. :-)

Re: Ready to start serious work on VC mode again

[Eric S. Raymond]

Stephen J. Turnbull <stephen@xemacs.org>:
> Just bit the bullet and go to the bleeding edge, Eric.  It's not like
> you've never been there before. :-)

Well, no.  But on any given project I like to stick to only *one*
bleeding-edge critical dependency.  This help[s preserve my sanity.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Ready to start serious work on VC mode again

[David Kastrup]

"Eric S. Raymond" <esr@snark.thyrsus.com> writes:

> Are there any know, urgent VC bugs I should address first?

Things that hit me is that using multiple backends does not appear to be
robust.  I have some CVS directory with some files checked into git (but
not all).  When I use C-x v l to get a log file from a file only present
in git, and then type RET on some log entry, vc bombs out because it
wants to see the file being in CVS.

Those logs should likely use a local variable to hardware the VC they
are supposed to work with.

I have had other problems with files not registered under CVS (but in a
CVS-controlled directory) but under git but don't remember the details
right now.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Ready to start serious work on VC mode again

[Eric S. Raymond]

David Kastrup <dak@gnu.org>:
> "Eric S. Raymond" <esr@snark.thyrsus.com> writes:
> 
> > Are there any know, urgent VC bugs I should address first?
> 
> Things that hit me is that using multiple backends does not appear to be
> robust.  I have some CVS directory with some files checked into git (but
> not all).  When I use C-x v l to get a log file from a file only present
> in git, and then type RET on some log entry, vc bombs out because it
> wants to see the file being in CVS.
> 
> Those logs should likely use a local variable to hardware the VC they
> are supposed to work with.

Noted; I'll look into this.

Actually, the fact that this is the only "known, urgent" bug report
I've received is encouraging.  Multiple back ends is kind of a wacky
edge case; if this is the worst problem VC currently has, it's in
*good* shape.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Ready to start serious work on VC mode again

[Nick Roberts]

 > > > Are there any know, urgent VC bugs I should address first?
 > > 
 > > Things that hit me is that using multiple backends does not appear to be
 > > robust.  I have some CVS directory with some files checked into git (but
 > > not all).  When I use C-x v l to get a log file from a file only present
 > > in git, and then type RET on some log entry, vc bombs out because it
 > > wants to see the file being in CVS.
 > > 
 > > Those logs should likely use a local variable to hardware the VC they
 > > are supposed to work with.
 > 
 > Noted; I'll look into this.
 > 
 > Actually, the fact that this is the only "known, urgent" bug report
 > I've received is encouraging.  Multiple back ends is kind of a wacky
 > edge case; if this is the worst problem VC currently has, it's in
 > *good* shape.

I've not followed VC development closely but surely this can't be right.  Dan
(or someone else) has placed a whole load of TODO items in vc.el.  I still use
vc-dired instead of vc-dir because it doesn't respect
vc-stay-local/vc-cvs-stay-local.  You will also find issues in the archives,
e.g.,

http://lists.gnu.org/archive/html/emacs-devel/2008-04/msg00664.html

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: Ready to start serious work on VC mode again

[Eric S. Raymond]

Nick Roberts <nickrob@snap.net.nz>:
>  > Actually, the fact that this is the only "known, urgent" bug report
>  > I've received is encouraging.  Multiple back ends is kind of a wacky
>  > edge case; if this is the worst problem VC currently has, it's in
>  > *good* shape.
> 
> I've not followed VC development closely but surely this can't be right.  Dan
> (or someone else) has placed a whole load of TODO items in vc.el.  I still use
> vc-dired instead of vc-dir because it doesn't respect
> vc-stay-local/vc-cvs-stay-local.  You will also find issues in the archives,
> e.g.,
> 
> http://lists.gnu.org/archive/html/emacs-devel/2008-04/msg00664.html

Noted.  I've added both these items to the TODO in my copy; I'll be tackling
some of the more obvious fixes today and tomorrow.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Ready to start serious work on VC mode again

[Stephen J. Turnbull]

Eric S. Raymond writes:

 > Multiple back ends is kind of a wacky edge case;

I don't agree.  Multiple back end workspaces are going to be quite
common *among the population of people who are likely to turn into
vc.el hackers*.  DAK obviously uses them, I do, Barry Warsaw (Mailman
maintainer and Python release engineer) uses them on at least three
projects, and that's just a few folks I know.

You want this feature to shine, I think.

Re: Ready to start serious work on VC mode again

[Paul R]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

>
>  > Multiple back ends is kind of a wacky edge case;
>
> I don't agree.  Multiple back end workspaces are going to be quite
> common *among the population of people who are likely to turn into
> vc.el hackers*.  DAK obviously uses them, I do, Barry Warsaw (Mailman
> maintainer and Python release engineer) uses them on at least three
> projects, and that's just a few folks I know.
>
> You want this feature to shine, I think.

Does anybody have a clear idea about how VC should behave in such a
situation ?
Should it warn when opening a file because this file is under 2 or
more vcs ? Should user be prompted at this point to choose which to
use for next VC commands on this file ? Should user be able to save
its preference for each file ? For each project ?

-- 
      Paul

Re: Ready to start serious work on VC mode again

[Sean O'Rourke]

Paul R <paul.r.ml@gmail.com> writes:
> Does anybody have a clear idea about how VC should behave in such a
> situation ?

As a user currently (but hopefully not for long) dealing with
multiple backends, I would prefer:

    1. Respecting the order of `vc-handled-backends' by default.
    2. Whenever a backend creates a non-file buffer, using that
       backend's functions called from that buffer.

Does that cover things?

Sean

Re: Ready to start serious work on VC mode again

[David Kastrup]

Paul R <paul.r.ml@gmail.com> writes:

> "Stephen J. Turnbull" <stephen@xemacs.org> writes:
>
>>
>>  > Multiple back ends is kind of a wacky edge case;
>>
>> I don't agree.  Multiple back end workspaces are going to be quite
>> common *among the population of people who are likely to turn into
>> vc.el hackers*.  DAK obviously uses them, I do, Barry Warsaw (Mailman
>> maintainer and Python release engineer) uses them on at least three
>> projects, and that's just a few folks I know.
>>
>> You want this feature to shine, I think.
>
> Does anybody have a clear idea about how VC should behave in such a
> situation ?
> Should it warn when opening a file because this file is under 2 or
> more vcs ? Should user be prompted at this point to choose which to
> use for next VC commands on this file ? Should user be able to save
> its preference for each file ? For each project ?

vc-handled-backends is a variable defined in `vc-hooks.el'.
Its value is 
(GIT RCS CVS SVN SCCS Bzr Git Hg Mtn Arch MCVS)


Documentation:
List of version control backends for which VC will be used.
Entries in this list will be tried in order to determine whether a
file is under that sort of version control.
Removing an entry from the list prevents VC from being activated
when visiting a file managed by that backend.
An empty list disables VC altogether.

You can customize this variable.

This variable was introduced, or its default value was changed, in
version 23.1 of Emacs.


-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Ready to start serious work on VC mode again

[Stefan Monnier]

>> > Multiple back ends is kind of a wacky edge case;
>> 
>> I don't agree.  Multiple back end workspaces are going to be quite
>> common *among the population of people who are likely to turn into
>> vc.el hackers*.  DAK obviously uses them, I do, Barry Warsaw (Mailman
>> maintainer and Python release engineer) uses them on at least three
>> projects, and that's just a few folks I know.
>> 
>> You want this feature to shine, I think.

> Does anybody have a clear idea about how VC should behave in such a
> situation ?

Currently, there are 2 ways to control it:
- vc-handled-backends whose order influences which backend is used
  by default.
- C-x v b which allows you to switch to another backend.

The fact that backends are currently associated to filenames is the
source of the problems we need.  They should be associated to
buffers instead.


        Stefan

Re: Ready to start serious work on VC mode again

[David Kastrup]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> > Multiple back ends is kind of a wacky edge case;
>>> 
>>> I don't agree.  Multiple back end workspaces are going to be quite
>>> common *among the population of people who are likely to turn into
>>> vc.el hackers*.  DAK obviously uses them, I do, Barry Warsaw (Mailman
>>> maintainer and Python release engineer) uses them on at least three
>>> projects, and that's just a few folks I know.
>>> 
>>> You want this feature to shine, I think.
>
>> Does anybody have a clear idea about how VC should behave in such a
>> situation ?
>
> Currently, there are 2 ways to control it:
> - vc-handled-backends whose order influences which backend is used
>   by default.
> - C-x v b which allows you to switch to another backend.

Oh, by the way:  I find that C-x v b does switch to a different backend,
but the mode line is not adapted accordingly.  Also, it somehow
considers RCS and CVS to be the same, which is pretty confusing.

> The fact that backends are currently associated to filenames is the
> source of the problems we need.

We need them?

> They should be associated to buffers instead.

Or buffers should be able to override the association with a
buffer-local binding.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Ready to start serious work on VC mode again

[Eric S. Raymond]

David Kastrup <dak@gnu.org>:
> > [Back ends] should be associated to buffers instead.
> 
> Or buffers should be able to override the association with a
> buffer-local binding.

You may have to write this yourself if you want it. There are two problems 
blocking a solution from me.  

One is that the mode has *other* significant design problems that
could eat all my coding time for quite a while.  One of the largest,
which I'm going to post about here in more detail shortly, is
designing a command set that has sensible behavior on both
file-oriented and repo-oriented VCSes.  Following my big rewrite the
back ends now handle this distinction just fine, but there are *nasty*
problems in the front-end design proceeding from the seemingly
innocuous question "under what circumstances do we allow
(vc-deduce-fileset) to return an empty select set, and what does it
mean when we do?".  If trying to map out the Right Thing under all the
different circumstances this comes up doesn't make your head hurt, you
haven't grasped the problem yet.

Two is that I would prefer to actively neglect
mixed-VCS-in-one-directory usage.  I've said this before and
listmembers have protested, but I think it's a classic example of
allowing the preoccupation of hackers with one complex little edge
case to do bad things to the maintainability of the rest of the code.
I'm not going to personally try to "fix" this until all the other
known bugs and wishlist issues more interesting to normal VC users are
resolved.  And I'm not going to fix it at all if the complexity
overhead of doing so turns out to be too high; I'd rip out all traces
of the incomplete mixed-VCS support instead.

So, as I said, if you want this solved, you'll probably have to dig in
and do it yourself.  And work hard at making it small and elegant,
because I think this feature has low value and my willingness to accept 
crufty code in support of it is accordingly minimal.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>