Re: [Mageia-dev] packages branches and revision numbers when submiting packages with mgarepo
Sorry for the delay. On 29.01.2011 16:30, nicolas vigier wrote: On Sat, 29 Jan 2011, Anssi Hannula wrote: AFAICS the above branch scheme doesn't work well with changelog generation. As changelog is generated from [packagename]/releases, one of two things seems bound to happen: a) There is no [packagename]/releases under the branch, and the changelog gets messed up (all commits since initial package import in a single release entry), or b) One tries to keep [packagename]/releases to preserve sane changelog when branching, but this will fail as this SVN command is invalid, as one can't copy a directory into itself: svn cp /packages/cauldron/[packagename] /packages/cauldron/[packagename]/branches/[branchname] Good question. I have looked at how it is working now : - it first looks at all svn logs from [packagename]/releases, and extract infos from %repsys markrelease logs, which contains infos about packages version, release, and relrevision. - it use commit logs from [packagename]/current and groups them by package releases using the infos from markrelease. So I think we can do this : - We don't copy releases directory in branches, only SPECS and SOURCES directories, we share the releases directory for current and branches. - In %repsys markrelease commits, we include the branch name - When generating logs for a branch package we only use markrelease infos from that branch, and from current from before the first markrelease for the branch - When generating logs for current package, we ignore markrelease from other branches Does it look ok ? What if branches are moved / branched to other branches? Also, that won't preserve the changelogs of branches when they are merged back (not 100% sure if that is wanted, though). -- Anssi Hannula
[Mageia-dev] packages branches and revision numbers when submiting packages with mgarepo
Hello, In Mandriva using repsys it was possible to provide a svn revision number when submitting a package. It is still possible to do it using mgarepo, but with a separate repository for binary files, it is more difficult. The current version of mgarepo tries to find the right revision to use for the binrepo (revision from the same date as the revision on the specs repository), but it is not always working as expected. I started to add an option to be able to specify the binrepo revision to use when submiting, but after thinking about it, it's probably not a good idea, because it becomes too complicate. With repsys it's also possible when submiting packages to give an URL instead of a package name. This allows creating new branches for a package. However we also have a problem with this with binrepo, as we need to find the right path for the binary repository. We could add an option to give the URL for the binaries, but I don't think it's a good idea. So I propose to do this instead : - We won't allow using revision numbers when submiting packages. Instead we always use the latest revision available on svn. I don't think submit with a revision number are used much (but maybe I'm wrong ?) and a branch copied from a revision can be used instead, to do the same. And not supporting revision numbers will make mgarepo code more simple. - We won't allow submit with a URL, but only with a package name (and the right URL will be generated by the script receiving the submit request on pkgsubmit). To allow using branches, instead we add a --branch option to provide the name of a branch. If no branch name is provided we use the package from this path : /packages/cauldron/[packagename]/current If a branch name is provided we use the package from this path : /packages/cauldron/[packagename]/branches/[branchname] And the same path in the binrepo. Some commands can be added in mgarepo to create, remove, checkout branches. With this, the path for branches will be more clear, and the same for all packages (contrary to Mandriva where packages could have some branches in /packages/branches, or in /packages/updates, /packages/updates_release or /packages/cooker or anywhere on the repository). Does anyone see any problem with this ? Or other ideas, or comments ?
