Tchize wrote: > Also, what is support for symbolic tagging within one repository 'No' > on svn, SVN has support for tags, and because tags&branch create a new > urls in svn, it make it easy to retrieve a specific version or branches > using that url. You can even mix tags if you want (tag only some folders > or get different revision of different folder under a same tag) > >From what I understand, creating a 'tag' in SVN is essentially creating a new branch, and on on the list of version control system criteria that Mark posted, which I based the matrix on, doing tags AS a 'branch', like SVN does doesn't count. (also if one were to count what SVN does for 'tags' as being sufficient, Mercurial should also get a 'Yes') > The ability to do local branch (which is suppose mean creating a local > repository, working on it and then push your local repository branch to > main server) is marked as 'no' for svn, but according to some doc, it > can be done with SVN-Mirror or SVN-Pusher, it's client side tools you > can install to create your own repository. > I've never heard of SVN-Pusher, and only vaguely remember hearing of SVN-Mirror, but personally, if I want to use local branches frequently (which I have often found myself wanting to), I'm not sure I would trust SVN-Mirror and SVN-Pusher to handle all of the obscure cases of merging, or how well SVN-Mirror handles incremental changes, compared to systems that are designed with local branching in mind. Also, I wouldn't really like having to rely on a separate perl tool for such functionality. > Tracking when merge are done is not No on svn, but svn docs about > branching and merging explicitly explain how to track it efficiently and > easily. > I think I found the documentation you're referring to: http://svnbook.red-bean.com/nightly/en/svn.branchmerge.copychanges.html#svn.branchmerge.copychanges.bestprac.track And yes, it's not hard to track it manually, but I would consider automatic tracking of such like distributed systems do to be a major advantage with regards to branching. > I have never heard of darcs, bzr and hg before, but if we get to free > hosting service for those tool, we need to ensure those service won't > disappear in the next 3 years. Sourceforge is a solid corporation held > by VA linux. > Well, in terms of bzr, launchpad.net hosts bzr repositories for projects, and that's funded by Canonical Ltd. (the people who fund Ubuntu), so I doubt that would be going away for quite some time. For mercurial, as I mentioned in a different message, Dotsrc.org (formerly SunSITE.dk) looks like a possible option, and they have numerous corporate sponsors (including Sun, HP, and many others), not to mention how I've seen sunsite.dk mirrors of things around for a very long time, so I doubt they'll be going away. > The best solution to decide will probably be a vote amongst commiters as > everyone probably has it's preferences. Agreed.
Alex Schultz _______________________________________________ crossfire mailing list [email protected] http://mailman.metalforge.org/mailman/listinfo/crossfire
