Re: selfupdate-git

On Wed, Aug 1, 2012 at 3:14 PM, Max Horn <[email protected]> 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

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

_______________________________________________
fink-core mailing list
[email protected]
List archive:
http://news.gmane.org/gmane.os.apple.fink.core
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-core