On Monday, 20 April 2009 14:17:38 Michael Schroeder wrote:
On Mon, Apr 20, 2009 at 12:12:16PM +0200, Andreas Gruenbacher wrote:
On Monday, 20 April 2009 11:20:17 Michael Schroeder wrote:
Otherwise links to linked packages can't work.
I really don't see why not.
Because you're referencing a fixed set of files, i.e. an *expanded* package if the target is also a link.
Okay, let's extend the previous example to the following link-link situation: A A / \ / \ B A' d(AB) A' / | | / | | C B' A'' d(BC) d(AB') A'' Now we have an additional package C which is a source link. The original versions of the packages can be reconstructed from what the build service stores, like this: B = apply(d(AB), A) B' = apply(d(AB'), A) C = apply(d(BC), B) = apply(d(BC), apply(d(AB), A)) Now let's assume that a new revision of C shall be created. The codebase that we want to generate C' against is a merge of A'' and B. (Without links of links, the codebase will always be a normal revision.) We can depict this as follows: A / \ B A' / \ \ C B' A'' \_ \ / \_ \ / \_ o \| C' If we describe things in terms of what the build service stores, we end up with this: o = apply(d(AB'), A'') The expanded version of C is: apply(d(BC), o) The user modifies this expanded version, resulting in C'. Finally, diff(o, C') is computed and stored. That's all fair enough. Ideally we would be doing a three-way merge wherever we now apply a patch, but this is not what I would like to focus on right now. I would like to do achieve two things though: (1) compute the original version of C' as it was generated. This means that I either need to know the files in o (the srcmd5), or the list of revisions that lead to o (assuming that I can reproduce how the backend created o, i.e., apply the patches in the right order). Since the srcmd5 seems to be readily available, I would prefer to have it instead of having to rely on reproducing things correctly. (2) reconstruct the tree of revisions. I don't see how I could do that based on the srcmd5 of o alone without a lot of trying, so if the list of revisions that went into o could be stored in the revision that describes C', that would be much preferred. I also have a question related to how the build service computes expanded packages and links: assume that in th eabove example, the user checks out the expanded version of C, and starts working on C'. Before committing C', somebody else creates A'''. When computing the diff for C', how does the backend know to diff against o = apply(d(AB'), A'') rather than against the now-current codebase apply(d(AB'), A''')? Does the client submit back the srcmd5 that was used to the server? Thanks, Andreas -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org