Re: [fink-core] selfupdate-git

[Dustin C. <dus...@us...>]

On Wed, Aug 1, 2012 at 3:14 PM, Max Horn <ma...@qu...> wrote:

>  > This would make it easier to make changes on 10.4 and then sync them
> over to 10.7 or vice versa. In fact, it would be nice to have a different
> branch for each version (10.5, 10.6, 10.7, and 10.8) if there was someone
> to keep 10.5 "tied" with 10.6 and 10.7 "tied" with 10.8. This makes EOL'ing
> an OS version straightforward: just stop automatically synching it.
>
>
> How would that work, from a technical point of view? Keep in mind that it
> should be as automated as possible, else it won't happen (we are already
> lacking manpower). Do you mean this: In the conversion, we would have a
> 10.7 and a 10.8 branch. However, these branches would refer to the same
> commit. Whenever something is committed to the 10.7 branch, the 10.8 branch
> is automatically increment to still point to the same branch as 10.7. That
> is, until the day were we decide that the two branches need to diverge
> (e.g., because 10.7 support ends, or for any other good reason). After
> that, the separate syncing would stop. However, if some individuals still
> want to maintain the EOLed 10.7 tree, they could be granted permission to
> do so (just as is happening with the "10.4-EOL tree right now, only much
> more elegantly).
>
> The crucial part here seems to me the question on how to keep the two
> branches in sync... Perhaps a special hook script in the repos could take
> care of that.
>

I mean this, but I had no answer as to how the branches would be kept in
sync.

A simpler (in terms of technical requirements) solution would be to do
> this: We start out with just two branches, 10.4 and 10.7. Then, we somehow
> provide a map which maps Distribution values to branch names (this map
> could be part of the dists repository, so that it gets updated along with
> the packages when doing a selfupdate). E.g. it could initially contain this:
>  10.4 => 10.4
>  10.5 => 10.4
>  10.6 => 10.4
>  10.7 => 10.7
>  10.8 => 10.7
>
>  When we EOL 10.4 support (well, we already did, of course), then what we
> do is this: We create a new 10.5 branch, based on 10.4. And update the map
> to look like this:
>  10.4 => 10.4
>  10.5 => 10.5
>  10.6 => 10.5
>  10.7 => 10.7
>  10.8 => 10.7
>
> And so on. Advantage: No hooks or technical tricks required.


This seems like a better idea in all respects.

Dustin


>
> > One big downside is that changing the repository structure probably
> means that the CVS history can't be copied into the git repository.
>
> I think that's not a serious problem. Indeed, I think we could arrange
> things so that the 10.4-EOL stuff would become the 10.4 branch, while the
> regular parts of 10.4/ would become the 10.5 branch. Indeed, I think with
> some effort and good user of git filter-branch, this is no problem at all
> :).
>
>
> >
> > That's my case for git, but I agree that it is harder to use than svn.
> Part of the reason is that git supports many different workflows. One way
> to make this easier is to have wrappers which handle implement whatever the
> policy will be for submitting packages, which is the most common task that
> most developers will need.
>
> As I said, I love git myself... I am just reluctant to force all
> maintainers to use it, because whhile I appreciate the many advantages it
> brings, I have too often experienced the pains it can also bring to the
> "not yet enlightened". ;).
>
> Hence, I really, *really* hope we can get the dual git + svn approach to
> work well...
>
>
>
> Cheers,
> Max