On Thu, Mar 01, 2012 at 11:45:40AM +0300, Alexey Shvetsov wrote:
> Not sure if its for council.
I don't think it's suitable for council, but it does need more
discussion than it's been getting on the scm list.
> Define timeframe for cvs->git migration. Technical issues almount
> 1. Thin manifests already in portage
> 2. Git commit signing already there (if git-1.7.9 will be keyworded due
> to issue with svn 1.7 [git-svn functionality with SVN 1.7 if your
> SVN repo URL, branch name or tag names contains characters that need
> URL escaping])
Do you have a fix for the Git SVN 1.7 problem then?
Other items not included in the above, that we need some agreement on.
- Initial tree state:
Single commit, signed by me, with a graft of history available as a
separate download (it's ~1200MB) . This ensures that all of the
history is available AND that the usual downloads for developers are
Alternatively, how much history should we include in the base
- Log generation
- Potentially dropping Changelogs in Git (generate
shortly during rsync tree generation?)
- Merge policies
This is the hardest political topic.
Do we force users to rebase before they push to the tree?
Before you say yes, of course, there is a catch:
If the user publishes their work in MORE than one place, and does push
to remote A/master, pull from remote B/master, rebase master on
B/master, push to remote B/master. Now what do they do about the state
of remote A? They _HAVE_ to either have a merge of A/master, or
destroy the history at A/master with a forced push.
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail : email@example.com
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85