Hi, Am 19.05.2008 um 18:04 schrieb Brecht Machiels:
As Andreas pointed out sometime ago, BepFiles only make sense for releases, and not so much for trunk revisions. I suppose group porting efforts will also focus on the trunk versions?
Either trunk or branches, yes; tags would also be an option. It should be decided from case to case.
Maintainers probably won't like it if changes are only submitted for some "old" branch but not for trunk, in most cases changes to branches would be backports from trunk. On the other hand, when we don't know a software too well, it may be better to port a stable branch first and only then check whether trunk works as well. It all depends.
I don't think there's any problem installing any VCS of our liking on the new port.haiku-files.org server.
I'm still a little behind with my mail, so let me shoot from the top of my head:
I really welcome Koki's server offer, a big thank you. In addition to hopefully resolving the Trac issues I'd hope the Haiku domain will move the project even closer to the Haiku community at large. I just hope it'll still be considered okay to provide non-Haiku legacy information then.
In which way exactly do we have access to that server? Is there a user limit? Hosting writable repositories for distributed versioning systems in most cases requires SSH access for each contributor. Space could also become an issue since a distributed repository contains most of the history of the original one. Is the server running some Linux, so that we could easily install precompiled software and services?
Although, I am wrestling a bit with getting Trac to work on it :/
If you tell us what problems you are facing with Trac, maybe someone can help! :)
It might make sense to set up repositories on a project basis though.So, for porting SVN or CVS projects we might use Git (don't knowMercurial[2]/Bazaar[3] too well, but Git seems easier to use on Haikufor now with the others' dependency on Python); for a project using Git obviously use Git, for a project using Bazaar use Bazaar etc. Personally I have found Git to better handle merges than SVN/CVS butit seems to lack an equivalent to the svn copy operation for files. Ifwe don't want to or can't host such repositories on our own server, for Git repo.or.cz would be an option, for Bazaar launchpad.net. Anyway, +1 for using *some* distributed versioning system for group efforts.haven't really used git or any of the other distributed version control systems yet. I think it's definitely worth to examine whether any of them could be used for a unified ports tree. Or if not, whether a server couldFrom what I've heard about git, it sounds quite nice at least, but Ibe set up to host individual repositories.
Git for instance does not use custom URLs like SVN does. There are only "global" branches and tags; multiple disjoint projects inside one repository would risk name clashes and are unhandy for obtaining the code (cloning the repo).
Andreas -- BePorts homepage - http://tools.assembla.com/BePorts List archives: //www.freelists.org/archives/beports Administrative contact: brecht@xxxxxxxxxxx
