[haiku-commits] Re: r37181 - in haiku/branches/developer/zooey/posix-locale/src/tests/system/libroot/posix: . posixtestsuite posixtestsuite/Documentation posixtestsuite/conformance posixtestsuite/conformance/behavior ...
- From: Niels Reedijk <niels.reedijk@xxxxxxxxx>
- To: haiku-commits@xxxxxxxxxxxxx
- Date: Sun, 20 Jun 2010 20:43:33 +0200
Hi,
On 20 June 2010 16:42, Oliver Tappe <zooey@xxxxxxxxxxxxxxx> wrote:
> Hi Ingo,
>
> On 2010-06-20 at 11:56:01 [+0200], Ingo Weinhold <ingo_weinhold@xxxxxx> wrote:
>> On 2010-06-20 at 00:04:25 [+0200], Oliver Tappe <zooey@xxxxxxxxxxxxxxx>
>> wrote:
> [ ... ]
>> > I have tried to find out why exactly this happened, but I'm not quite sure.
>> > It
>> > certainly looks as if subversion didn't like these order of things:
>> >
>> > 1. I created the posix-locale branch
>> > 2. Ingo deleted posixtestsuite in trunk
>> > 3. Ingo added (the full) posixtestsuite in trunk
>> > 4. I tried to merge changes 2 + 3 into posix-locale
>> >
>> > I find this "tree conflict" quite scary, especially since I didn't touch
>> > posixtestsuite at all in my branch.
>>
>> Which svn version were you using?
>
> 1.6.4 as client, 1.6.11 as server. AFAICS, that combination should be able to
> handle tree conflicts gracefully, but it just didn't.
>
>> Anyway, I still think we should switch to a distributed VCS which do have
>> less issues with branching and merging, besides other nice features.
>
> Yep, so do I.
>
> I'm not looking forward to having to merge posix-locale back to trunk one day.
I am quite far in working on a hg to svn bridge. The basic logic is
implemented. In short: I have implemented a way for the distributed
logic to be converted to the svn repository. This means that pushing
changes to a centralized hg repository will be converted to the svn
repository. I will write a blog post about how it works and which
choices the bridge makes during conversion.
The good news is that you might now use a hg repository to develop
separate features in. You will be able to merge these with the central
repository (as often and easy as you like) and push these to the
central repository if you like (and then continue to use that tree).
I reckon a similar logic could be implemented for git.
Note though that this is different from things like git-svn,
hgsubversion and hgimportsvn. Those only work for local (single user)
conversions of an svn repository, not for distributed, shared, branchy
development.
So Oliver, I would challenge you to switch to hg (or git) for your
developer branch!
N>
Other related posts:
