Migrating SourceForge repository from Bazaar to Git

[Bill Wohler]

Thanks to your motivation, I'm currently researching the best way to
migrate our SourceForge repository to Git. While I'm doing that, please
push any changes you may have outstanding. I noticed that I had one
change to the Developers Guide that I hadn't checked in.

Mike and Jeff, please respond when you are done modifying the
repository.

[Mike Kupfer]

Post by Bill Wohler
Mike and Jeff, please respond when you are done modifying the
repository.

All clear from my end.

mike

------------------------------------------------------------------------------

[Bill Wohler]

Post by Mike Kupfer

Post by Bill Wohler
Mike and Jeff, please respond when you are done modifying the
repository.

All clear from my end.

OK, thanks.

I replaced the "Code" tool with git. See
https://sourceforge.net/p/mh-e/git/ and clone with:

git clone ssh://$***@git.code.sf.net/p/mh-e/git mh-e

This is considered a test repository until we hear from Jeff.

Now that we don't have the Bazaar shared repository nonsense, I'll clean
up the directory structure (mh-e/mh-e -> mh-e).

The Developers Guide and Makefiles for this repository check out the
Emacs repository into src/emacs. However, I'm now thinking it makes more
sense to check out the Emacs repository into ../emacs by default so that
the mh-e and emacs directories will be in the same directory. For
example, you'd end up with /usr/local/src/emacs and /usr/local/src/mh-e
instead of /usr/local/src/mh-e/src/emacs. Any objections or suggestions?

I'll update the Makefiles and Developers Guide accordingly, and push out
the 8.6 release to test the changes, opening up 8.7 for your new stuff.

[Jeffrey Honig]

I do not have any changes pending for our repo.

Post by Bill Wohler

Post by Mike Kupfer

Post by Bill Wohler
Mike and Jeff, please respond when you are done modifying the
repository.

All clear from my end.

OK, thanks.
I replaced the "Code" tool with git. See
This is considered a test repository until we hear from Jeff.
Now that we don't have the Bazaar shared repository nonsense, I'll clean
up the directory structure (mh-e/mh-e -> mh-e).
The Developers Guide and Makefiles for this repository check out the
Emacs repository into src/emacs. However, I'm now thinking it makes more
sense to check out the Emacs repository into ../emacs by default so that
the mh-e and emacs directories will be in the same directory. For
example, you'd end up with /usr/local/src/emacs and /usr/local/src/mh-e
instead of /usr/local/src/mh-e/src/emacs. Any objections or suggestions?
I'll update the Makefiles and Developers Guide accordingly, and push out
the 8.6 release to test the changes, opening up 8.7 for your new stuff.
--
http://www.newt.com/wohler/
GnuPG ID:610BD9AD
------------------------------------------------------------------------------
_______________________________________________
mh-e-devel mailing list
https://lists.sourceforge.net/lists/listinfo/mh-e-devel

[Bill Wohler]

Cool, thanks! Then the Git repository is now considered official.

Comments on the directory structure welcome; otherwise, I'll proceed as
described.

Happy New Year everybody!

Post by Jeffrey Honig
I do not have any changes pending for our repo.

Post by Mike Kupfer

Post by Bill Wohler
Mike and Jeff, please respond when you are done modifying the
repository.

All clear from my end.

OK, thanks.
I replaced the "Code" tool with git. See
This is considered a test repository until we hear from Jeff.
Now that we don't have the Bazaar shared repository nonsense, I'll clean
up the directory structure (mh-e/mh-e -> mh-e).
The Developers Guide and Makefiles for this repository check out the
Emacs repository into src/emacs. However, I'm now thinking it makes more
sense to check out the Emacs repository into ../emacs by default so that
the mh-e and emacs directories will be in the same directory. For
example, you'd end up with /usr/local/src/emacs and /usr/local/src/mh-e
instead of /usr/local/src/mh-e/src/emacs. Any objections or suggestions?
I'll update the Makefiles and Developers Guide accordingly, and push out
the 8.6 release to test the changes, opening up 8.7 for your new stuff.
--
http://www.newt.com/wohler/
GnuPG ID:610BD9AD
------------------------------------------------------------------------------
_______________________________________________
mh-e-devel mailing list
https://lists.sourceforge.net/lists/listinfo/mh-e-devel
----------------------------------------------------
----------------------------------------------------
------------------------------------------------------------------------------
_______________________________________________
mh-e-devel mailing list
https://lists.sourceforge.net/lists/listinfo/mh-e-devel

[Mike Kupfer]

Post by Bill Wohler
I'm now thinking it makes more
sense to check out the Emacs repository into ../emacs by default so that
the mh-e and emacs directories will be in the same directory.

Sounds okay to me.

Post by Bill Wohler
I'll update the Makefiles and Developers Guide accordingly, and push out
the 8.6 release to test the changes, opening up 8.7 for your new stuff.

Great, thanks!

mike

------------------------------------------------------------------------------

[Bill Wohler]

Post by Mike Kupfer

Post by Bill Wohler
I'm now thinking it makes more
sense to check out the Emacs repository into ../emacs by default so that
the mh-e and emacs directories will be in the same directory.

Sounds okay to me.

Well, this didn't work. If we want to use the same Makefile in both the
distribution and in our development environment, we'll need an emacs
directory, or more clever plumbing. For now, I punted. However, a
symbolic link works nicely.

I updated the BAZAAR MH-E INSTALL section in the README quite a bit and
added the symbolic link idea. Here's a preview. Let me know what you
think.


* MH-E DEVELOPMENT ENVIRONMENT INSTALLATION

Non-developers can check out the MH-E development environment with:

git clone git://git.code.sf.net/p/mh-e/git mh-e

Then run `make emacs' or just `make' in the `src' directory to check
out Emacs, which includes MH-E proper, from Savannah. Then follow the
steps that apply to you in INSTALL above.

Developers can check out the MH-E development environment with:

git clone ssh://$***@git.code.sf.net/p/mh-e/git mh-e

Then run `make emacs-devel' to check out Emacs using the $USER
environment variable as their Savannah login. If you already have
Emacs installed, you can first create a symbolic link to it called
`emacs' from the `src' directory. For example:

cd src
ln -s /usr/local/src/emacs

[Bill Wohler]

Post by Mike Kupfer

Post by Bill Wohler
I'm now thinking it makes more
sense to check out the Emacs repository into ../emacs by default so that
the mh-e and emacs directories will be in the same directory.

Sounds okay to me.

I've pushed my changes to the contrib, doc, and src directories. Please
follow the developer directions in the last message (clone, create emacs
link to existing source code tree or run make emacs-devel to create a
clone within the MH-E sources) and let me know how it works for you.

Oh, it is so much nicer to be using Git!

Post by Mike Kupfer

Post by Bill Wohler
I'll update the Makefiles and Developers Guide accordingly, and push out
the 8.6 release to test the changes, opening up 8.7 for your new stuff.

Great, thanks!

Onward!

[Mike Kupfer]

Post by Bill Wohler
Then run `make emacs' or just `make' in the `src' directory to check
out Emacs, which includes MH-E proper, from Savannah. Then follow the
steps that apply to you in INSTALL above.

IIUC, the instructions will result in a full copy of the Emacs repo,
with HEAD set to the master branch. While that's fine, I think there
should be some text in the README for people who want the current
release branch.

The rest of the text looks good to me.

mike

------------------------------------------------------------------------------

[Bill Wohler]

Post by Mike Kupfer

Post by Bill Wohler
Then run `make emacs' or just `make' in the `src' directory to check
out Emacs, which includes MH-E proper, from Savannah. Then follow the
steps that apply to you in INSTALL above.

IIUC, the instructions will result in a full copy of the Emacs repo,
with HEAD set to the master branch. While that's fine, I think there
should be some text in the README for people who want the current
release branch.

I think the audience for the GIT MH-E section is someone who wants the
master branch, no?

Post by Mike Kupfer
The rest of the text looks good to me.
mike

[Mike Kupfer]

Post by Bill Wohler
I've pushed my changes to the contrib, doc, and src directories. Please
follow the developer directions in the last message (clone, create emacs
link to existing source code tree or run make emacs-devel to create a
clone within the MH-E sources) and let me know how it works for you.

I was able to clone the MH-E Git repo okay. I added a symlink to an
existing emacs-25 Git repo and tried to build the htdocs tree so that I
could peruse the Developers Guide. This failed with

nice make
make[1]: Entering directory '/home/kupfer/ws/mh-e/htdocs/doc'
makeinfo -I ../../doc/doc/emacs --html --no-split --output devguide.html devguide.texi
devguide.texi:2348: @include: could not find gpl.texi
../Makefile.rules:19: recipe for target 'devguide.html' failed
make[1]: *** [devguide.html] Error 1
make[1]: Leaving directory '/home/kupfer/ws/mh-e/htdocs/doc'
Makefile:14: recipe for target 'all' failed
make: *** [all] Error 1

I was able to build the User Manual okay.

Hmm, looks like I need to build in the doc tree before trying to build
in htdocs--my 2nd attempt in htdocs succeeded. Could you add something
to the makefile(s) so that the setup in the doc tree happens
automatically if I start in htdocs? Or add a README to htdocs, saying
to build in "doc" first.

If you'd like, I can try creating a makefile patch, but it'll be a few
days before I can get to it.

thanks,
mike

------------------------------------------------------------------------------

[Bill Wohler]

Post by Mike Kupfer

Post by Bill Wohler
I've pushed my changes to the contrib, doc, and src directories. Please
follow the developer directions in the last message (clone, create emacs
link to existing source code tree or run make emacs-devel to create a
clone within the MH-E sources) and let me know how it works for you.

I was able to clone the MH-E Git repo okay. I added a symlink to an
existing emacs-25 Git repo and tried to build the htdocs tree so that I
could peruse the Developers Guide. This failed with
nice make
make[1]: Entering directory '/home/kupfer/ws/mh-e/htdocs/doc'
makeinfo -I ../../doc/doc/emacs --html --no-split --output devguide.html devguide.texi
../Makefile.rules:19: recipe for target 'devguide.html' failed
make[1]: *** [devguide.html] Error 1
make[1]: Leaving directory '/home/kupfer/ws/mh-e/htdocs/doc'
Makefile:14: recipe for target 'all' failed
make: *** [all] Error 1

Yep, that was the first thing I fixed in the devguide, but I haven't
pushed it yet.

Post by Mike Kupfer
I was able to build the User Manual okay.

Cool.

Post by Mike Kupfer
Hmm, looks like I need to build in the doc tree before trying to build
in htdocs--my 2nd attempt in htdocs succeeded. Could you add something
to the makefile(s) so that the setup in the doc tree happens
automatically if I start in htdocs? Or add a README to htdocs, saying
to build in "doc" first.

That's true. My preference would be for it to be handled in the
Makefile, but a README suggestion is a close second. I'll make it so.

Post by Mike Kupfer
If you'd like, I can try creating a makefile patch, but it'll be a few
days before I can get to it.

No worries, it's been fixed, just not pushed. Thanks!

Post by Mike Kupfer
thanks,
mike

[Mike Kupfer]

Post by Bill Wohler
I think the audience for the GIT MH-E section is someone who wants the
master branch, no?

It depends on what they want to work on. Whizzy new features would
indeed go on the master branch. Bug fixes would go on the current
release branch.

I suppose the MH-E documentation could give the instructions for getting
the master branch, note the existence of release branches, and refer the
reader to http://www.emacswiki.org/emacs/GitForEmacsDevs for
instructions on how to work with the current release branch.

mike

------------------------------------------------------------------------------

[Bill Wohler]

Post by Mike Kupfer

Post by Bill Wohler
I think the audience for the GIT MH-E section is someone who wants the
master branch, no?

It depends on what they want to work on. Whizzy new features would
indeed go on the master branch. Bug fixes would go on the current
release branch.
I suppose the MH-E documentation could give the instructions for getting
the master branch, note the existence of release branches, and refer the
reader to http://www.emacswiki.org/emacs/GitForEmacsDevs for
instructions on how to work with the current release branch.

The README is for users who don't want to work on anything, although
they may want to check the latest out from Git. The master branch will
have everything they want. In the very unlikely case that we check
something in on an Emacs release branch, it will be merged into master.

I think your audience is covered by the Developers Guide, which mentions
GitForEmacsDevs.

[Mike Kupfer]

Post by Bill Wohler
The README is for users who don't want to work on anything, although
they may want to check the latest out from Git.

Okay, I guess I got confused by the section heading. Instead of

MH-E DEVELOPMENT ENVIRONMENT INSTALLATION

I think something like

BUILDING THE LATEST MH-E DEVELOPMENT CODE

or

BUILDING MH-E FROM GIT

would be clearer. (Or "INSTALLING..." instead of "BUILDING...".)

Post by Bill Wohler
The master branch will
have everything they want.

It may also have stuff that they don't want (like if someone wants to
alpha-test the next release), and it may be less stable than the release
branch. I don't know how closely you're following emacs-devel, but I
recall seeing at least one email asking that folks focus on the emacs-25
branch for now, rather than on master.

Post by Bill Wohler
In the very unlikely case that we check
something in on an Emacs release branch, it will be merged into master.

This is sort of an aside, but I think "very unlikely" is an inaccurate
characterization. When there's a current release branch, that's usually
where bug fixes will go.

mike

------------------------------------------------------------------------------