Am 07.03.2010 12:03, schrieb Dieter Plaetinck: > Couldn't find any discussion about this, > but what about we maintain our packages in git instead of svn? > > pros: > 1) git is awesome > 2) we don't need abs/rsync anymore. users can just read from git. > 3) git network communication is more efficient then rsync (afaik) > 4) users can check out older versions of packages easily, with > limited storage overhead. > 5) makes it easier to maintain forks of packages (have your > own git repository with some changes, then merge in upstream changes to > keep them up to date. upstream == arch linux here) This comes up every month at least (not necessarily on the mailing list, but somewhere) and people always say "use git" without even thinking how that would work - so far, nobody has ever presented a workflow that would match our packaging requirements and was based on git. We don't use SVN for fun - using SVN is everything but fun. 1) We want to be able to see which PKGBUILD matches the package in the repository. In SVN, we use copy - which is subversion's equivalent to branching: By copying, you create a reference and all history of the copied file is still there. In git, copying means that the copy has no history, it is entirely unrelated to the original. The only equivalent in git would be branching - but you cannot branch a single file or path, you can only branch the entire tree. 2) Partial checkouts and commits: We check out single directories and most importantly we commit to single directories without updating the rest of the repository. These operations come naturally to SVN, but they are against the very concept of git. The only viable solution I could think of is using one git repository per package - and that is just crazy.
Attachment:
signature.asc
Description: OpenPGP digital signature
