thank you. I've setup an own subversion here just to check and practice
some things before checking-in some code.
I want to be sure, that nothing is going wrong ;-)
73's de Adi, DL1HRC
> OK, Adi. I have added you as a project member now and given you write access
> to Subversion. I'll lay out some guidelines for Subversion usage here:
> 1. For now, I want to be the only one checking code into trunk. That includes
> merging from branches unless I say otherwise.
> 2. Try to keep branches as clean as possible. One branch should contain one
> new feature, if possible. Try to avoid lumping a lot of new features into one
> "personal" branch. The risk here is that the branch will grow larger while new
> features are added but not finished. Creating separate branches for each
> feature will encourage finishing implementing a feature so that it can be
> merged to trunk and then merged into other branches that need it.
> 3. When creating a new branch, always do that from trunk and not from a
> subdirectory: svn cp ^/trunk ^/branches/my_branch, where ^ is an alias for the
> repository root. This will reduce confusion.
> 4. You are responsible for keeping your branches in sync with trunk. This is
> to make later merging easier and of course so that you get the latest features
> into the branches. It's pretty easy to do as well unless lots of changes
> conflict. Then it can be a bit of a pain. This should not be a big problem
> unless we start to have a lot of overlapping features being developed at the
> same time. Just do a "svn merge ^/trunk" now and then. You may need to modify
> that path, depending on how you checked out the svxlink source tree (e.g. svn
> merge ^/trunk/src).
> About point 2, if one wants to test multiple features at the same time that
> are in development in different branches you should be able to have one more
> test branch where you merge all other branches to. Development is always done
> in the separate branches, checked in and then merged to the test branch for
> long time testing. The test branch is never merged back to trunk but instead
> discarded when not needed any more. The separate branches are merged to trunk
> when a feature has been finished and can then be discarded. To be honest, I
> have not tried this way of working before but I think it could work pretty
> 73's de SM0SVX / Tobias
>> Thank you again, my sf-login is my callsign (lowercase).
>> 73's de Adi, DL1HRC
>> On 22.02.2011 21:28, Tobias Blomberg wrote:
>>> Hi Adi,
>>> On Monday 21 February 2011 18.14.04 Adi Bier wrote:
>>>> Hi Tobias,
>>>> is there a chance, that I get a rw-access on sourceforge to the
>>>> phonelogic-branch and/or an other directory e.g. branch/contrib/dl1hrc ?
>>>> I think it's easier to handle it and I do not have to setup an own
>>> Yes, I've been thinking of doing this for a while. I can not, I think,
>>> just give you access to a couple of branches though. It's either write
>>> access or not, to the whole repository.
>>> This should not be a problem as long as you accept to only check stuff in
>>> into your branches. You can even create new branches if you want but I
>>> want to be the only one who check stuff into trunk.
>>> What is your user name on SourceForge? I need that to add you as a
>>> project member.
>>> Note: I'm not going to start giving out rw access to just anyone that
>>> develop some small thing. There should be a real need and at least some
>>> bigger patches should have been contributed before rw access can come
>>> into question.
>>> 73's de SM0SVX / Tobias
>>>> 73's de Adi, DL1HRC
> Free Software Download: Index, Search& Analyze Logs and other IT data in
> Real-Time with Splunk. Collect, index and harness all the fast moving IT data
> generated by your applications, servers and devices whether physical, virtual
> or in the cloud. Deliver compliance at lower cost and gain new business
> insights. http://p.sf.net/sfu/splunk-dev2dev
> Svxlink-devel mailing list