On Jan 17, 2008, at 10:20 PM, Jyri Virkki wrote: > > Creating it is easy enough, we can certainly do that. >
It has already been created and may be cloned with the following command: hg clone ssh://anon at hg.opensolaris.org/hg/webstack/memcached-incubator The repository contains two branches: default (containing our changes) and memcached (containing the upstream repository). The diff between the repositories is generated with the following command: hg diff -r memcached > I'd like to see some detail on how you'll be managing the differences > that build up between the repositories? We will push all relevant changes out to the community as soon as possible. We have no guarantee that our patches will be accepted or included in the upstream repository, or when they will include them. (They have not applied the patches I have submitted yet: * Fix alignment in the memory allocator (to avoid core-dumps on sparc in 32-bit mode) * Update the source to C-99 * Optimized the read-loop to avoid "unneeded" system calls. We want those changes in the source code while we're working. I find it more difficult to track the actual change I did for another feature in the same file if I need to apply those changes to my file while I'm working. I find it easier to track the changes now that they exists as separate changesets in Mercurial. I don't know when the patches will be applied, but I do need them for my work (at least the alignment patch). > In the current sfw src model the upstream tarballs are kept as-is and > there are a limited number of patches (ideally zero) which are applied > at build time. This is kind of a pain, but it has the benefit of > clearly tracking each distinct patch. As a side effect, it also > discourages changes that aren't absolutely needed. I believe that our integration to sfw will also consist of the released tarball and a patch containing the patches we need in order to make it work. The Mercurial repository is for us to incubate the changes upstream. We are not trying to fork or diverge from the upstream project. > If you do all the work on a private repository it'll be easier to > introduce more change "while I'm editing this file". > Yes, that is a challenge for us, but since it will generate extra merge costs for us whenever we merge with the upstream repository, I guess that we will try our best to avoid doing so ;-) > Ideally all the components are identical to the upstream tarball, so > more change == bad. > We hope that the upstream repository accepts and incorporates our patches so that the repositories is more or less in sync all the time. Our repository will also contain change history for changes we did and decided not to use anyway (and reverted the change). The log history describing why we decided that it was not a good idea after all adds valuable information (if another developer gets the same idea later on can then just look in the change log to find out why it's not a good idea after all)... > It also makes it a bit more work to track individual patches (for > submitting upstream) since there might be unrelated changes to the > same file so just running a diff won't give you the correct patch for > a single bug. That is a challenge, but it is a case that we might come into anyway. Lets take an example: If we wanted to add a feature (lets say DTrace probes) but the upstream project refused to include it for some reasons. A diff from now on would also include our dtrace probes... Please note that I don't suspect that they will refuse to accept our patches. We will try to publish individual patches as soon as possible upstream. Trond
