On Tue, Dec 22, 2009 at 1:24 PM, Dagobert Michelsen <[email protected]> wrote: > When we are talking about automation it may be useful to work towards > automatic build: When someone makes a tag the comment to the tag may > include the relevant message what has changed since the last tag only.
I tend to disagree with the tagging idea. Tags are good when you want to preserve a version of the build before making major changes. You can argue that tags are good for marking certain revisions of interest, and package releases could count. But it strikes me as a model which doesn't take into account other factors playing role in how we work with subversion. There are two main problems with it. One is that we don't have the habit of using tags and I don't think we'll acquire it unless it's mandatory. If you make it mandatory, it will be annoying to people and will do more harm than good. If it won't be mandatory, nobody will use it, because it will make no benefit to the maintainer. The second problem is that if we start tagging every release, our source repository will quickly become so crowded, that doing a checkout of the gar/pkg directory will take forever. You can even try to estimate the time based on current checkout speed and the projected number of files after, say, a year. I really like the current setup in which the package has an embedded information about the subversion path from which it was built, and the revision number. You don't need more. If you have this information, you can work out which release was built from which revision. If we want something faster than downloading and dissecting a package, we can cache this information in a database. I think we can achieve the same functionality (automated builds) in a more transparent, non-intrusive way. Maciej _______________________________________________ maintainers mailing list [email protected] https://lists.opencsw.org/mailman/listinfo/maintainers
