On Wednesday 18 November 2009 19:24:45 P Zoltan wrote:
> We should define the way to access the upstream repository.
IMHO, we should handle upstream just as we do with SVN at the moment. git is
about distribution. This means, every copy (in git terms: clone) is it's own
repository. You can sync between different repositories very easy. This is
done by "push"ing or "pull"ing (depends on the direction). This upstream
repository is designated as "our truth". Every development is done based on
branches from the upstream repository. This means, every developer should make
sure, patches apply without problems against the upstream branch, before
requesting a merge. Distribution works, if we find a consensus on how to deal
with patches. This "upstream"-approach is a useful pattern, how to solve this
problem. Technically it's a simple repository like all the others out there,
but if we agree it to be the central repository, it would be less pain merging
from all different sources.
I admit, it takes some time, to get used to this form of source-code
management. I am using it heavily for about a year, now. The first few weeks
were somewhat frustrating, because I had many questions and some problems :)
But now, I don't want to give it up, again.
> Also I couldn't find any documentation about the usage of multiple source
> code management systems for sourceforge.
Mhh, why should sf.net bother about this? If I had implemented it, there would
be an option: add SCM and remove SCM. Just like you add or remove hosted-apps.
I don't want the SVN repository to be deleted, so we maybe should ask some
sf.net staff, if it's possible and how to proceed.