On Dec 12, 2013, at 19:20 , Michael Schroeder <mls(a)suse.de> wrote:
On Thu, Dec 12, 2013 at 01:44:34PM +0300, Kanstantsin
I did more debug and found :
- .mrev has duplicated entries during creation -
Yeah, that's a bug in the API or WEBUI.
- no need to increase revision when makeolder
Why not? That really depends on your use case. As copying always
resets the "rebuild counter", we always bump the revision so that
the freshly build packages are "newer" than the old ones.
will be right if i copy .rev without changes in srcserver and history+meta in repserver.
- why you do renumbering for ?withhistory??
Because we can't have multiple revisions with the same id. If the
package did not exist before, it will get the same ids.
But this is a problem only
in case when we want increase vrev (and that’s why do additional commit) that has no sense
when we have makeolder that adds the second commit.
- lsrev() and addmeta() are changing hashes for
SERVICE entries => it enough to just copy existed .rev with MD5SUMS files
Not in all cases. Maybe if "noservice" is given. Otherwise, all services
are re-run (or course only for the latest revision).
Even with noservices.
- why do you need random generator for SERVICE
entries? It can avoid new revision when nothing changed (related
Because the result does not only depend on the package content, but
also on the services configured in the project. And, maybe more important,
if the service is of the "fetch this url" type, the result may be
different files, so we need to have a different identifier for the
No matter how service configured, you have resulted files from what you can
do md5 and then create summary md5, so when service fetch the same files you will have the
same hash. And this can avoid new MD5SUMS with the same content + avoid new revisions.
That's not true for package links, here the result only depends on
the link content, so we don't need to have to create unique ids.
- copying .rev without changes allow to be in
sync with ?history? entries, i think it make sense to pass ?withhistory? option to
rep_server so it copy ?history? and meta files?
checkin history and meta files only live on the source server, so passing
that to the repo server makes no sense.
:meta/$pack and $pack/history lives in
/build/project/repo/arch/ directory so if i use withhistory+withbinaries+ no makeolder - i
can have one in one copy of project.
I think we can have all variants of copy (including without rebuild) using existed
Michael Schroeder mls(a)suse.de
SUSE LINUX Products GmbH, GF Jeff Hawn, HRB 16746 AG Nuernberg
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-buildservice+owner(a)opensuse.org