On Sat, 20 Aug 2016, Ian Wadham wrote: > On 20/08/2016, at 1:24 PM, Lawrence Vel�zquez wrote:
> > We'll actually be using svn2git for the migration, so in a very real sense > > we have you (collectively) to thank :) > > > > https://techbase.kde.org/Projects/MoveToGit/UsingSvn2Git That was broken for a while, though it seems to be back now. There are multiple articles kicking around on possible migration issues, e.g.: Migrating from Subversion to Git and the Lessons Learned | Dr Dobb's http://www.drdobbs.com/architecture-and-design/migrating-from-subversion-to-git-and-the/240009175 Don't do svn-to-git repository conversions with git-svn! | Armed and ... http://esr.ibiblio.org/?p=6778 > I don't know if this applies to Macports, but KDE did a lot of splitting of > SVN > "module" repositories into individual project repositories on git. For > example, > the KDE Games module on SVN went from one repository to about 40 repositories: > one for each game and library. This was to limit the overheads, for > developers, > of cloning git repositories in their local machines, but it made building > "everything" > (i.e. collections of repositories) a little harder. Given that git has the ability to make "shallow" clones (with the --depth argument), this doesn't seem like a very good reason to split things up and make nontrivial cloning *more* hassle. Disclaimer: I've never bothered using this feature myself, since I have plenty of disk space and a fast net connection. :-) Git also has a "submodule" feature, but it was added as an afterthought and in the one project I've contributed to that uses it (OSXFUSE), it's been more trouble than it's worth. On Sat, 20 Aug 2016, Brandon Allbery wrote: > On Sat, Aug 20, 2016 at 11:44 PM, Ian Wadham <iandw...@gmail.com> wrote: > > > Fork the repo?? > > > github expects you to do this, yes. I don't actually recommend it because > keeping up to date with the original repo's a PITA (and *not* automated in > any way. https://help.github.com/articles/syncing-a-fork/ is annoyingly Umm, the whole merging aspect is something you need to do regardless of whether you're pulling from "origin" or "upstream", so this isn't a good argument against using a fork. It gets more complicated with multiple branches, but again the merging part is the same whether you're using a fork or not, and the only difference is whether you also need to push the merged branches to the fork. Meanwhile, the whole pull request mechanism is designed around the forked repo model, so anyone without direct commit access should be strongly encouraged to use a fork. And even for someone *with* direct commit access, a fork provides a backed-up sandbox for changes that aren't ready for the main repo (even in a branch). There's a slight difference in whether you need to specify "upstream" in the "fetch" or "pull" (since you don't normally want to make "upstream" the default remote), but that's pretty minor. > manual). You lose the ability to maintain your clone with github's web > interface, but that's not much of a loss really. (Or you can do their thing > in reverse: clone the repo, add github as an additional upstream, create a > new empty repo (not a fork) via their web interface, push to github > periodically as a backup.) You *can* do that, but it doesn't really simplify anything, so it's mainly only useful in cases where the main repo isn't hosted on GitHub (and hence where "fork" is meaningless). BTW, it's worth mentioning that "fetch" doesn't touch the working directory or index at all, so it can safely be done at any time. Then after fetching, all the fetched commits are available locally for examination, diffing, etc. Fred Wright
_______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev