Following on from comments before about a better method being needed for the MUSHclient source, and to eventually save me time and effort, I am migrating it to Git. You can see the preliminary results here for version 4.45:
With bzr, you would "tag it" as a given version by creating a branch and calling that branch whatever you wanted. I presume that git has a similar mechanism.
In order to make the git repository look reasonable (ie. unlike the way I normally work <grin>) I have tidied things up a bit ...
Files that didn't seem relevant to compiling or installing were removed
A whole lot of files were moved to subdirectories, to make the main top-level directory less cluttered. For example, scripting, xml, mxp, dialogs and more, are all now in their own subdirectories.
To reflect these changes, various modifications were made to the source (eg., changing #include directives)
The source distribution does not include major libraries not written by me, in particular:
pcre
png
sqlite
zlib
Instead, a readme.txt file has been placed in the appropriate directories indicating how you might obtain those libraries, and make minor amendments to get them to compile OK.
The installer file (mushclient.nsi) was modified to point to the relevant new directories, where applicable.
The resulting source *should*, if downloaded and compiled, yield version 4.45 of MUSHclient. However because of the changes mentioned (eg. to include paths etc.) it is not literally the source used to compile the released version 4.45.
The resulting "head" has been "tagged" as v4.45, indicating that if you retrieved the files "as at v4.45" (and don't ask me how to do that just yet) you should get the version 4.45 source.
As for tagging stable releases, an approach I'm considering for my own projects is having two branches: 'stable' and 'development'. Work is done in 'development', and when a new version is ready for release, you just switch to the stable branch and merge in development, then add a tag like 'v4.45' for easy access. It gives the stable branch a tidy history of stable releases, and if you want to see more in-depth development history, you can look at the development branch.
David: From what I've read, git tags are basically just nonmoving branch heads, which sounds pretty much exactly the same as the bzr mechanism as you described it.
The nice thing about the bzr method of using branches to "tag" releases -- and I don't know if the git "nonmoving branch heads" do the same but I would presume they do -- is that each release can have its own directory and branch, as separate from the main development and stable branch. You can then merge changes from arbitrary branches into arbitrary other branches. (They have smart storage implementation to not duplicate information unnecessarily in the VCS database.)
So what you would do is similar to what you described, except that instead of (or in addition to, as your needs vary) tagging the stable as 4.45, you would branch it off.
This is more helpful when you need to apply maintenance patches to old versions, but MUSHclient's development doesn't really work that way. Old versions become obsolete as new versions come out, unlike some projects where version X is still supported when version X+1 comes out.
To do a maintanence patch as you describe, you'd simply checkout the tagged version you want to patch, then commit a new patch and re-tag it. It would create a new branch off of the original release, and the later versions' histories wouldn't be affected. This could be a good or bad thing depending on how you look at it, but I doubt bzr works much different.y
Near the top of the page (at present) I see a box like this:
Updated version number to 4.46
commit 218d75b45ed72085d7ea41236378d098b8d8e5ab
tree 66c7d35b20e29c9876ea2d1f790ad1551f8d76db
parent 248df7579b22bbb444453d47529d03b169e5bef2
nickgammon (author)
4 minutes ago
Now if you click on the "commit" link (the hex stuff in bold) then it opens a new page, somewhat like the following box.
Inside that (in a nice colour presentation) is a listing of everything in that commit:
If you have a local version checked-out (eg. with the "clone" command) then you can see what differences have been made in files since the last version, like this:
git diff v4.45 -- lua/wait.lua
The two dashes are necessary to separate the commit tag (v4.45 in this case) from the file name(s).
Apparently, and I haven't tried this yet, you can compare between any versions like this:
You can immediately see from this which files have changed at all, and then what the changes were by looking at individual files. For example, the install/readme.txt file:
If you select the "raw" option you can see the text OK.
I strongly suspect this is to do with characters on the page with the high-order bit set (some other pages with the copyright symbol on them did it, before I got rid of it).
I suspect that GitHub is trying to interpret the page as UTF-8, and failing, but why? Does anyone know enough about Git to tell me how to stop it doing that? Eg. to tell it that pages are iso-8859 rather than UTF-8? Or is it just a bug?
Git itself should be encoding-agnostic according to the documentation I've seen, so it's probably GitHub that's at fault. However, it does seem that utf8 is the preferred/standard web encoding.
This ticket seems to show the same issue, but I can't tell what they did exactly to fix it. [1]
Yes, well in the case in question it was doing something like:
switch (blah)
{
case 'X' : blah
}
... where X was something like a C with a cedilla. Now, I can't make that utf-8 as it is in C where I am trying to match a single byte (not a UTF-8 sequence).
However a quick search revealed only a small number of these cases, so I recoded like this:
switch (blah)
{
case '\xC7' : blah
}
That still works programmatically, and should display OK.
Once a new release has appeared you can show the commit log, like this:
$ git log --pretty=oneline --reverse v4.45..v4.46
248df7579b22bbb444453d47529d03b169e5bef2 Added flags to matching in wait.lua
218d75b45ed72085d7ea41236378d098b8d8e5ab Updated version number to 4.46
29a1228ffbad95c2c305cef2560e9a777dadfbb6 Put back stuff I accidentally took out
038e366fc6a81ad2595de5c727686feeae5f063c Added PPI module
efbb9d35ffcd5c20e4ef0077844c6b8c6ad8c6ad Allow empty text documents to be marked read-only
447dc727ced0d2f02464197fc2b29f9baa9a0060 Stuff for having hotspots outside plugins
4016d779a76193026b214f0dfaf5cf82b102c58a documentation improvements
adde6adb0ff1a413afec0155b6dfc1f21ef126dc Stuff for having hotspots outside plugins
49a77b31fa20252d463a510a10b950ccb4477ff8 Added WindowGradient to list of known functions
b0e2a46db1773e111d18ee085bfa6418b570131d Fixed loop in Linux on disconnect
ff995fbb3628dd3da41b96e435806425864c9939 Documentation generation files
4f4fb446ecd7865db740e172c0a0f03d5b96a43f Final changes before release
b020fc56b0904a6c60002874fca54532c36e0592 ignore file for docgen directory
fc0ec85769e076e8b1a2b1d44a96ef2a146bc065 Added help work file
Notice the "version tag" range at the end of the command (v4.45..v4.46). Also the --reverse option shows the commits in date order, the default is the most recent commit first.
You can also see what files were affected in the version release by doing a diff, like this:
This gives the actual file names that have changed, so you know which ones to investigate further (eg. by doing a diff on them).
Another way of looking at the change log is to generate the names of changed files per commit, like this:
$ git log --pretty=oneline --name-status --reverse v4.45..v4.46
248df7579b22bbb444453d47529d03b169e5bef2 Added flags to matching in wait.lua
M lua/wait.lua
218d75b45ed72085d7ea41236378d098b8d8e5ab Updated version number to 4.46
M MUSHclient.rc
M doc.h
M install/readme.txt
29a1228ffbad95c2c305cef2560e9a777dadfbb6 Put back stuff I accidentally took out
M doc.h
038e366fc6a81ad2595de5c727686feeae5f063c Added PPI module
M install/mushclient.nsi
A lua/ppi.lua
efbb9d35ffcd5c20e4ef0077844c6b8c6ad8c6ad Allow empty text documents to be marked read-only
M TextDocument.cpp
447dc727ced0d2f02464197fc2b29f9baa9a0060 Stuff for having hotspots outside plugins
M OtherTypes.h
M doc.cpp
M miniwindow.cpp
M mushview.cpp
M mushview.h
M scripting/methods.cpp
4016d779a76193026b214f0dfaf5cf82b102c58a documentation improvements
M .gitignore
M readme.txt
adde6adb0ff1a413afec0155b6dfc1f21ef126dc Stuff for having hotspots outside plugins
M dialogs/plugins/PluginsDlg.cpp
49a77b31fa20252d463a510a10b950ccb4477ff8 Added WindowGradient to list of known functions
M scripting/functionlist.cpp
b0e2a46db1773e111d18ee085bfa6418b570131d Fixed loop in Linux on disconnect
M worldsock.cpp
ff995fbb3628dd3da41b96e435806425864c9939 Documentation generation files
A docgen/help.hpj
4f4fb446ecd7865db740e172c0a0f03d5b96a43f Final changes before release
M MUSHclient.dsp
M MUSHclient.opt
M install/readme.txt
M scripting/functionlist.cpp
b020fc56b0904a6c60002874fca54532c36e0592 ignore file for docgen directory
A docgen/.gitignore
fc0ec85769e076e8b1a2b1d44a96ef2a146bc065 Added help work file
M .gitignore
Now you can see for each individual commit (change) which files were affected.
Hullos. Could I ask why in particular the Github repository source requires you to download the other libraries separately? That is, is there a license issue or something? I ask because it's somewhat annoying and error-prone to download the file and make the changes required to fit it to the MUSHclient source. If there was some way to put the external libraries source in the repository as well, it would also guarantee that those who download the source will have exactly the library versions required.
Well it seems like duplication, and also they aren't really my libraries. I admit I did it for the fairly small lsqlite library, but that is only one file, 56 Kb in size.
Other ones like Sqlite3 are over 1 Mb, and lots of files. PCRE library: 5 Mb. PNG library: 3 Mb.
The instructions are pretty straightforward - I followed them myself for the last build. And once you have the libraries you don't really need to re-get them for every build.
As an example of what other people do, in the instructions for the PNG library they say:
Before installing libpng, you must first install zlib, if it is not already on your system. zlib can usually be found wherever you got libpng. zlib can be placed in another directory, at the same level as libpng.
So if it is good enough for the PNG developers to require you to go to the extra effort of getting dependent libraries, I think it is good enough for MUSHclient.
Fair enough, thanks for the reply. By the way, though, in the last commit I pulled down, I had to modify all of the dialog/scripting files to look one directory higher for the other files they were including. Actually, I may have just added to the project's path for that, I can't remember... I'm going to redownload and compile later anyways, so I'll let you know what all I had to do to get it working.
I do remember that I had to install the DirectX SDK and add its paths to Visual Studio, so you may want to include that as one of the required steps. If I recall, it was for an #include "dsound.h".
OK, after lengthy changes, you don't need to put the MUSHclient directory in as a default include path. Now every file works up or down from where it should.
I do remember that I had to install the DirectX SDK and add its paths to Visual Studio, so you may want to include that as one of the required steps. If I recall, it was for an #include "dsound.h".
I don't think I have a list of required steps for the whole thing. But your point is taken, it is easy to forget you installed this stuff.
Alright, I got the source and set it up from scratch. It was fairly easy this time around, and I pushed the fixes I made upstream. I sent you a push request on GitHub, so you can grab my changes and see if it still under VC6.
EDIT: I also just edited your wiki page to include a brief set of steps to follow in order to build the source.
Since the dsound was mentioned recently, I figured I'd add in that MUSHclient works in "MiniXP" from Hiren's Boot CD, IF you bring a copy of the dsound.dll (windows\system32) and place into the mushclient folder.
Was working on someone's computer, and was waiting for a scan to complete (faster and cleaner to scan from within an OS booted "externally" to the issues) and wanted to pass the time somehow, and figured I'd go on an play a little. Thankfully the system I was working on had XP installed on it, so it was a cinch to get.
Just some random thought on the things being mentioned in this thread.
For anyone interested: I just happened across a reference to a 'gitk' utility while looking up again how to merge branches. It turns out it was installed along with the rest of the git utilities when I included the git package on Cygwin, and it creates a GUI view of the repository history, including a slightly GitHub-like graph of the network. Very awesome.