On Friday, 17 April 2009 14:03:15 Michael Schroeder wrote:
On Fri, Apr 17, 2009 at 11:59:05AM +0200, Andreas Gruenbacher wrote:
Yes, *exactly*. This is about what osc checks out, and it is about recording which revision of the target a link was generated against in the first place in order to even allow that.
That's pretty easy to add. I'll put a "keeplinkrev" attribute in the link when the link was created by the backend's "keeplink" mechanism.
Well, something like it, even though calling the revision of the target package that was used "keeplinkrev" sounds really odd to me. I would expect something like "trev" instead. This revision should be returned in status queries for a link package (<apiurl>/source/<project>/<package>[&rev=rev]). I would be using the trev and tsrcmd5 attributes for that. Note that those attributes are used today, but I don't think for anything useful and osc doesn't use them either, so I think they could be redefined to this meaning. From how I understand the code, the interaction between the client and the server goes like this: (1) The client sends a "cmd=copy&rev=upload&expand=1" request, which causes the server to create an expanded copy of the link package. It seems that the server does not allow the client to specify which revision of the target package to use. (2) The client modifies the expanded copy by changing, adding, and removing files. (3) The client sends a "cmd=commit&rev=upload&keeplink=1" request, which causes the server to generate the diff and create a new revision of the link package. Question 1: how does the client know which revision of the target package the server has used in step (1)? It must be ensured that the version of the link package that the client and server are using have both been expanded against the same version of the target package. Otherwise, changes in the target package may get lost in the link package. Question 2: what guarantees that when the server generates the diff in step (3), the diff is generated against save revision of the target package that was used in step (1)? (I assume there must be *something* in the code ensuring that, but I couldn't figure this out easily.) Thanks, Andreas -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org