[beports] Re: Changeset 60
- From: Ingo Weinhold <ingo_weinhold@xxxxxx>
- To: beports@xxxxxxxxxxxxx
- Date: Wed, 21 May 2008 16:30:22 +0200
On 2008-05-21 at 00:13:34 [+0200], Andreas Färber <andreas.faerber@xxxxxx>
wrote:
> 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.
Personally I prefer to port released versions and "port" the patch to
whatever the maintainers prefer before sending it upstream. When the patch
is accepted, there's little need to track any branch.
[...]
> >>> From what I've heard about git, it sounds quite nice at least, but I
> >> 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
> >> could
> >> be 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).
OK, so individual repositories indeed sound like the best choice in this
case.
CU, Ingo
--
BePorts homepage - http://tools.assembla.com/BePorts
List archives: //www.freelists.org/archives/beports
Administrative contact: brecht@xxxxxxxxxxx
Other related posts:
