[haiku-development] Re: merge branch
- From: Niels Reedijk <niels.reedijk@xxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Tue, 18 May 2010 11:09:58 +0200
Hi,
On 18 May 2010 00:26, Clemens Zeidler <clemens.zeidler@xxxxxxxxxxxxxx> wrote:
>> The feature that needs to be implemented is that when the h1-h3 +
>> merge changeset(s) are pushed, that that diff is committed to svn.
>> Then the hg-svn bridge needs to be taught that the whole sub-branch
>> corresponds to that revision in svn. Anyway, I will be looking at that
>> and possible solutions as my next project.
>>
>
> I see. But is it worth the effort? Whats about switching to hg (or a other
> distributed system) completely? Form the experiences of the last days svn
> was a way to slow for me. E.g. doing a branch diff takes several hours. I
> think you can use hg similar to svn by always pushing into the default
> branch. The only disadvantage I see is that you need an additional step to
> commit stuff (commit it locally and then push it to the server), but this is
> not necessarily a disadvantage. For example you can check your commit again
> before finally push it.
My next developer-tools project is going to be an hg<->svn bridge. I
hope to deliver a proof-of-concept soon (which would then also be
useful for a git<->svn bridge). The difference from hgsvn and
hgsubversion is that it is all done server-side, meaning the end user
does not have to bother with the logistics that it all involves.
About doing a switch: I have always maintained that you should look
closely at the nature of the project to decide which tools you should
use. Up until now this project has had a very centralized
organization, probably somewhat organized around the aspect that we
use SVN. The discussion should be whether another project topology
would yield better results, not which tool is cooler to use. That
really is a different thread though.
I will continue my implementation of the tool, and perhaps I can
announce a test project soon.
N>
Other related posts:
