[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Repository change to SVN, Jan 28th
From: |
David Ayers |
Subject: |
Re: Repository change to SVN, Jan 28th |
Date: |
Sun, 22 Jan 2006 19:04:16 +0100 |
User-agent: |
Mozilla Thunderbird 1.0.2 (X11/20051002) |
Sheldon Gill schrieb:
> Fred Kiefer wrote:
>
>> I also think that with the new possibilities of SVN there come a few
>> more rules that we need to set up and follow. We expect that SVN will
>> make it easier to have multiple branches with actual development going
>> on. Now what will be the rules for merging this branches back into the
>> main trunk? At work we are using ClearCase and have rather complicated
>> procedures that have to be followed to make this step save. Something
>> simpler might be enough for GNUstep. At least all changes from the trunk
>> need to be merged down first, conficts resolved and the code tested.
>> Then a review could happen, before the changes get actually merged.
>
>
> Actually, I think Fred has raised a good point here. We do, I think,
> need some clarification about branches and merging back to trunk. A few
> additional rules and guidelines may be useful. I've some questions:
>
> - are we going to stick with the SVN recommended 'trunk', 'branch' and
> 'tag'
I would like to see this.
> - how are branches to be named? What about sub-branches?
I believe there were some suggestions before. I had no objections but
also no strong feelings.
> - how are developers going to communicate about branches and what's
> going on in them?
I would suggest the Wiki.
> - what goes into tag? When?
You mean other than releases? Well since we have defined repository
states through revision numbers, I can't think of any necessity for more
tags. It's not like gnustep is seeing the kind of development activity
like, say, GCC. But maybe you have something specific in mind?
> - Are we going to import more vendor trees? (like ffcall, portaudio etc)
I think we should keep anything not FSF assigned in a separate
repository so we have clear boundaries from where we can blindly
copy-and-paste code. Other than that I think there should be a
dedicated maintainer(s) for any external vendor tree who will keep them
up to date.
Cheers,
David
- Repository change to SVN, Jan 28th, Adam Fedor, 2006/01/20
- Re: Repository change to SVN, Jan 28th, Fred Kiefer, 2006/01/21
- Re: Repository change to SVN, Jan 28th, Riccardo, 2006/01/22
- Re: Repository change to SVN, Jan 28th, Sheldon Gill, 2006/01/22
- Re: Repository change to SVN, Jan 28th,
David Ayers <=
- Re: Repository change to SVN, Jan 28th, Sheldon Gill, 2006/01/22
- Re: Repository change to SVN, Jan 28th, David Ayers, 2006/01/23
- Re: Repository change to SVN, Jan 28th, Sheldon Gill, 2006/01/23
- Re: Repository change to SVN, Jan 28th, Markus Hitter, 2006/01/23
- Re: Repository change to SVN, Jan 28th, Helge Hess, 2006/01/22