Automatically include the SVN Revision Number

[EmperorFool]

I've got the code working to do the check -- I just gotta find a good way to present it, plus figure out how to deal with non-SVN installs cleanly.

How would you all like it to work? I assume an option to check each time BUG starts up is a good start, and pop up a message when there's an update. Once it pops up a message, it should it tell you if there are more updates later?

What I mean is this. Say you are at 1000, and then someone commits 1001. It will tell you. If later someone commits 1002 but you haven't updated to 1001, should it tell you again that there are more updates? In other words, do you want to know about each update to SVN if you're staying at 1000?

I'm building a new tab that will show you your current revision and what the SVN repository is at. This is where you'll set whether to check or not and can change the repository location and local root directory (in case you update to X and export to Y).

 

[·Imhotep·]

Well, I'd definitely like to see further commits shown by the notifier. If it stays at 1001 I may think it's not a major revision, and therefore not doing the update instantly. If I see further commits it certainly makes updating more urgent. Of course I'm an update junkie, but that's another story...

 

[EmperorFool]

So an option to see each update, and in the popup window:

• The current vs. installed revisions (how many updates instead?)
• Button to open SVN log in external browser
• Button to do the update (need to install actual SVN command-line client)

What else?

 

[The Doc]

So an option to see each update, and in the popup window:

• The current vs. installed revisions (how many updates instead?)
• Button to open SVN log in external browser
• Button to do the update (need to install actual SVN command-line client)

What else?

Isn't that a bit over the top?

First it was just about "Automatically include the SVN Revision Number" and now you are implementing an auto-update system. Where did this thread take the wrong direction?

 

[Cammagno]

So an option to see each update, and in the popup window:

• The current vs. installed revisions (how many updates instead?)
• Button to open SVN log in external browser
• Button to do the update (need to install actual SVN command-line client)

What else?

What about moving Extra and BAT in different SVN repos?
I still think this is needed before making this feature working...

 

[EmperorFool]

Now you are implementing an auto-update system.

For me this was always the end-goal. Sure, I probably won't add the actual updating into BUG until I have no other features to add, but the key is to tell the user when updates are available, and how many.

What about moving Extra and BAT in different SVN repos?

While I'm thinking this may not be necessary, I created civ4bat at SourceForge and will be moving the files over soon. I'm dreaming of copying the history of the files, but I will more likely just copy the current versions and leave the history in civ4bug's repo.

If my idea to avoid splitting the projects doesn't work, I'll also move Extra Stuff to a civ4bug-extras project or something similar.

civ4beast? BUG Extras, Art, Site and Text! I had to use Extras for Help/Documentation. Got a better word? Here's what Extra Stuff contains now:

• Help / Documentation
• Art / Graphics: interface buttons, installer graphics and website
• Web / Site Backup: website
• Text / Copy: source text for some larger XML text entries (traits)

civ4what just doesn't have the same ring to it. And civ4shat probably gives the wrong impression.

 

[Cammagno]

While I'm thinking this may not be necessary

How?
The reason for this splitting, if I remember correctly, was mainly to avoid that, for example, an update in the ITA translation of an help file generates a new version number, so starting the do-you-want-to-update thing. IMHO this should be avoided, people doesn't care small changes in the help sources.
Instead, main updates to the help file will be detected, because the help files are in the BUG folder/repo.

 

[Cammagno]

civ4beast? BUG Extras, Art, Site and Text! I had to use Extras for Help/Documentation. Got a better word? Here's what Extra Stuff contains now:

• Help / Documentation
• Art / Graphics: interface buttons, installer graphics and website
• Web / Site Backup: website
• Text / Copy: source text for some larger XML text entries (traits)

civ4what just doesn't have the same ring to it. And civ4shat probably gives the wrong impression.

IMHO BEAST is ok, but in the form "BUG Extras: Art, Site and Text"
because help files are not in that folder, they are in the BUG and BAT folders, those in the Extra folders are source files, which are text files (so they can go under T) and in the future they will also be part of the website (so under S as well).

 

[EmperorFool]

How?

SVN keeps a revision number for every file and directory. You can see these when viewing the repository online, along with the history of each and which revisions touched which files.

As you can see on that page, we could pull the revision for the main directories for comparison. This has two downsides when compared with how I'm currently doing it (grabbing the global revision number from this page).

1. The more detailed page will be harder to parse, though not significantly. While the page may take longer to load, again it's unlikely to be noticeable.

2. It will be harder to estimate the number of updates between two revision numbers. Say you checkout revision 1000. Then someone makes 100 updates to the documentation. Finally someone else makes a single change to BUG. When you next check for updates, it will see 1101 and report 101 changes, yet only 1 was for BUG.

So I think I'm going back to splitting them out and using the global revision number again. Luckily that's how I coded it already.

The only problems with splitting them all is that we have to maintain three SourceForge projects (minor), and we lose the current history of BAT and the help files (also minor I think as it will still be in BUG if you need it).

 

[Cammagno]

So I think I'm going back to splitting them out and using the global revision number again. Luckily that's how I coded it already.

The only problems with splitting them all is that we have to maintain three SourceForge projects (minor), and we lose the current history of BAT and the help files (also minor I think as it will still be in BUG if you need it).

I think it's the best solution, and I agree that the downsides are minor ones.

But are you sure that you can't preserve the file history using the migrate command (with dump file)?
And I'll take into consideration the idea of asking for an umbrella project, to keep centralized trackers.

 

[EmperorFool]

But are you sure that you can't preserve the file history using the migrate command (with dump file)?

That's totally possible; I just would rather focus my energy on features. If you'd like to wrestle with SVN to pull down the dump file and put it into the other projects, I can certainly help with guidance. I haven't done it before, but I skimmed the docs.

And I'll take into consideration the idea of asking for an umbrella project, to keep centralized trackers.

Does SourceForge have umbrella projects, or do you mean just keep one of them as the umbrella? Honestly, I'm kinda looking forward to splitting apart the BUG and BAT trackers as it will free up the "group" field for another use. Not that there are too many BAT items in the trackers.

 

[Cammagno]

That's totally possible; I just would rather focus my energy on features. If you'd like to wrestle with SVN to pull down the dump file and put it into the other projects, I can certainly help with guidance. I haven't done it before, but I skimmed the docs.

Yes, I also read them some time ago, but I can re-read them quickly.
Even if we don't want to look for complex solutions, we can simply clone the actual project and then delete the BUG and Extra folders (or BUG and BAT folders) to have only the BAT folder (or Extra folder) with all its hystory.

Does SourceForge have umbrella projects, or do you mean just keep one of them as the umbrella? Honestly, I'm kinda looking forward to splitting apart the BUG and BAT trackers as it will free up the "group" field for another use. Not that there are too many BAT items in the trackers.

It has umbrella projects, even if I don't know/remember which other benefits we can get from using one of them.

 

[The Doc]

For me this was always the end-goal. Sure, I probably won't add the actual updating into BUG until I have no other features to add, but the key is to tell the user when updates are available, and how many.
[...]

I was just kidding. Great work as always.