On May 28, 2013, at 6:36 AM, Geert Janssens <[email protected]> wrote:
> You may have noticed that the mail notifications for gnucash-htdocs have a > new format with > the repository switched to pure git. > > The new notifications are generated by a script I found on the internet with > some gnucash > project-specific modifications. Most of the format has been discussed before > on this list. > > As we are now using it for the first time on a live, pure git repo some small > new things have > come up which I would like to point out and ask feedback on. > > 1. There seems to be an encoding issue somewhere. This is visible in the > notification mail for > the "svn_last" tag I generated: > Andreas Köhler is displayed as Andreas Köhler > I'll see if I can fix this. > > 2. I created a tag "svn_last" to mark the last commit in history that is > still in sync with our > now read-only svn repository. An unexpected side effect of this is that each > subsequent > notification message now starts with this tag in the subject line. Before, > the subject started > with the last commit's hashref. > I do actually prefer the tag usage. It gives an idea of what base the commit > is starting from. > On the other hand "svn_last" is not really descriptive for the current state > of the website. So I > probably should add two more tags (on on the master branch and one on the > beta branch). > I'm just wondering what would make sensible tags for the website ? We don't > really do > "releases" there. So a v2.4.x doesn't really make sense. What would ? > "stable" ? "prod" ? > "main" ? ... > > 3. Similar things will happen when we fully migrate gnucash and gnucash-docs > to git. Both > repositories already have a number of tags (for each release), but due to the > way the svn-git > bridge works none of these tags is actually on the trunk of 2.4 branch. > Instead each tag is a > separate branch with one commit and the (git) tag attached to it. In itself > this doesn't really > matter. > > 4. But it will affect the first real tags we add to the pure git repository. > My understanding of > the notification script is that when we add a tag to the repo it will search > for the most recent > previous tag on the same branch. It will then summarize the changes since > that tag. Again, > due to how the git-svn bridge works, we don't have any tags (yet) on our > primary > development branch (trunk/master). So the summary will be monstrous: all > commits starting > from the very first commit in cvs will be in there. I've seen this happen > with each release > since I added the git notification script (I had set up the system to send > mails to me privatly). > To avoid that, I would propose to add initial tags to each branch we consider > active once we > fully switch to git. At the minimum, we should add a tag for the most recent > release on the > trunk branch. That will likely be a future 2.5.x release or the 2.6 release > (depending on when > we do the last release of the 2.4 series). The one caveat: we can't add the > same tag to two > different commits. So if we want to tag releases that are tagged in svn as > well, we can't use > the same tag name. I don't know what would be best, but this is something we > should keep in > mind when we fully switch to git. Is this for commit-mail a.k.a gnucash-patches? You make it sound like every mail will recap history back to the last tag. That doesn't sound useful. We can just make a light tag (no message) on the last release commits; to prevent name collisions we can prefix them with "gnucash-docs" or "gnucash", so yesterday's tag will be "gnucash-2.5.2". I can't think of a useful tag for htdocs. It's not a repo that really has milestones. Maybe just tag the commit after svn_last with gnucash-htdocs-<branch name>? Regards, John Ralls _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
