2010/1/17 Marc Weustink <[email protected]>: > I certainly don't want to look in some > other repro. It's simply to much work.
[NOTE: I'm not starting another Git vs SubVersion thread, simply explaining for general interest, the difference between a central repository and a distributed repository workflow] Actually Marc, it wouldn't be much more work than what you already have to do by saving his patch from Mantis or his email, and then having to work through the patch and apply it to your repository to see it in action. In the case of Git repositories (and probably other distributed SCM's too), both your repository and his repository will have the same development lines. Only differences would be your local changes and his local changes. You would simply have to pull his branch containing the new feature, which will bring back only patch information (not his whole repository) and automatically create that same feature branch in your repository (no reed to save the patch or apply it - Git does that all for you). There will also be NO patch conflicts because his branch would have the same parent in your repository (which normally predates your local changes). You would then simply switch to that branch to see his code or use 'gitk --all' to view his changes (commits) in that feature branch (without switching your current branch). All this would be accomplished with one single command: git pull <his_repo_name_and_branch> Hardly much work. But SubVersion being a central repository system, developers only used to SubVersion would probably thing like you - that a distributed SCM is a lot of extra work - which in fact it actually is less effort. -- Regards, - Graeme - _______________________________________________ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ -- _______________________________________________ Lazarus mailing list [email protected] http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
