Trunk locked

[Aleksey Bragin]

Hello,
the trunk of our SVN server has been locked to prevent even more  
regression from entering the tree.

So far, after more than 3 weeks after I filed the bug report and not  
including all previous time when people were complaining about rapps  
which can't download anything at all - either hangs or crashes, I see  
that now even PCNet network card is being recognized in my VMWare  
Workstation 6.5.

Trunk is writable right now by members of the bugfix team only,  
that's so far Cameron (because he is the one supposed to fix  
networking) and me. If someone volunteers to fix any of the existing  
regressions, please let me know on irc/email, I'll include you into  
the bugfix team.

Thanks for understanding, and patience. My patience is over.

WBR,
Aleksey Bragin.

[KJK::Hyperion]

Aleksey Bragin wrote:
> the trunk of our SVN server has been locked to prevent even more  
> regression from entering the tree.

Great. Now unlock it
> Thanks for understanding, and patience. My patience is over.

My turn

[Ged Murphy]

I assume trunk is now unlocked??
There's been no mention of it but commits have restarted

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Aleksey Bragin
Sent: 17 November 2009 21:35
To: ReactOS Development List
Subject: [ros-dev] Trunk locked

Hello,
the trunk of our SVN server has been locked to prevent even more  
regression from entering the tree.

So far, after more than 3 weeks after I filed the bug report and not  
including all previous time when people were complaining about rapps  
which can't download anything at all - either hangs or crashes, I see  
that now even PCNet network card is being recognized in my VMWare  
Workstation 6.5.

Trunk is writable right now by members of the bugfix team only,  
that's so far Cameron (because he is the one supposed to fix  
networking) and me. If someone volunteers to fix any of the existing  
regressions, please let me know on irc/email, I'll include you into  
the bugfix team.

Thanks for understanding, and patience. My patience is over.

WBR,
Aleksey Bragin.

_______________________________________________
Ros-dev mailing list
[e-mail]
http://www.reactos.org/mailman/listinfo/ros-dev

[Gregor Schneider]

Aleksey announced via IRC that trunk is open for commits again.

2009/11/28 Ged Murphy [e-mail]
> I assume trunk is now unlocked??
> There's been no mention of it but commits have restarted
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Aleksey Bragin
> Sent: 17 November 2009 21:35
> To: ReactOS Development List
> Subject: [ros-dev] Trunk locked
>    Hello,
>
> the trunk of our SVN server has been locked to prevent even more
> regression from entering the tree.
>
> So far, after more than 3 weeks after I filed the bug report and not
> including all previous time when people were complaining about rapps
> which can't download anything at all - either hangs or crashes, I see
> that now even PCNet network card is being recognized in my VMWare
> Workstation 6.5.
>
> Trunk is writable right now by members of the bugfix team only,
> that's so far Cameron (because he is the one supposed to fix
> networking) and me. If someone volunteers to fix any of the existing
> regressions, please let me know on irc/email, I'll include you into
> the bugfix team.
>
> Thanks for understanding, and patience. My patience is over.
>
> WBR,
> Aleksey Bragin.
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[Ged Murphy]

You're probably all sick of me saying this (as I am saying it), but IRC is
the wrong place to make such announcements.

From: [e-mail] [mailto:[e-mail]] On
Behalf Of Gregor Schneider
Sent: 28 November 2009 16:40
To: ReactOS Development List
Subject: Re: [ros-dev] Trunk locked

Aleksey announced via IRC that trunk is open for commits again.

2009/11/28 Ged Murphy [e-mail]

I assume trunk is now unlocked??
There's been no mention of it but commits have restarted

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Aleksey Bragin
Sent: 17 November 2009 21:35
To: ReactOS Development List
Subject: [ros-dev] Trunk locked

Hello,
the trunk of our SVN server has been locked to prevent even more
regression from entering the tree.

So far, after more than 3 weeks after I filed the bug report and not
including all previous time when people were complaining about rapps
which can't download anything at all - either hangs or crashes, I see
that now even PCNet network card is being recognized in my VMWare
Workstation 6.5.

Trunk is writable right now by members of the bugfix team only,
that's so far Cameron (because he is the one supposed to fix
networking) and me. If someone volunteers to fix any of the existing
regressions, please let me know on irc/email, I'll include you into
the bugfix team.

Thanks for understanding, and patience. My patience is over.

WBR,
Aleksey Bragin.

_______________________________________________
Ros-dev mailing list
[e-mail]
http://www.reactos.org/mailman/listinfo/ros-dev

_______________________________________________
Ros-dev mailing list
[e-mail]
http://www.reactos.org/mailman/listinfo/ros-dev

[Sir Gallantmon]

Why the heck was the trunk even locked in the first place???

On Sat, Nov 28, 2009 at 11:06 AM, Ged Murphy [e-mail] wrote:
> You’re probably all sick of me saying this (as I am saying it), but IRC
> is the wrong place to make such announcements.
>
> *From:* [e-mail] [mailto:[e-mail]] *On
> Behalf Of *Gregor Schneider
> *Sent:* 28 November 2009 16:40
> *To:* ReactOS Development List
> *Subject:* Re: [ros-dev] Trunk locked
>
> Aleksey announced via IRC that trunk is open for commits again.
>
> 2009/11/28 Ged Murphy [e-mail]
>
> I assume trunk is now unlocked??
> There's been no mention of it but commits have restarted
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Aleksey Bragin
> Sent: 17 November 2009 21:35
> To: ReactOS Development List
> Subject: [ros-dev] Trunk locked
>    Hello,
>
> the trunk of our SVN server has been locked to prevent even more
> regression from entering the tree.
>
> So far, after more than 3 weeks after I filed the bug report and not
> including all previous time when people were complaining about rapps
> which can't download anything at all - either hangs or crashes, I see
> that now even PCNet network card is being recognized in my VMWare
> Workstation 6.5.
>
> Trunk is writable right now by members of the bugfix team only,
> that's so far Cameron (because he is the one supposed to fix
> networking) and me. If someone volunteers to fix any of the existing
> regressions, please let me know on irc/email, I'll include you into
> the bugfix team.
>
> Thanks for understanding, and patience. My patience is over.
>
> WBR,
> Aleksey Bragin.
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[Zachary Gorden]

To keep people from committing new changes that might break things.  This is
common practice before a release and has been done for at least the last
year or so.

On Sat, Nov 28, 2009 at 11:48 AM, Sir Gallantmon [e-mail] wrote:
> Why the heck was the trunk even locked in the first place???
>
> On Sat, Nov 28, 2009 at 11:06 AM, Ged Murphy [e-mail] wrote:
> > You’re probably all sick of me saying this (as I am saying it), but IRC
> > is the wrong place to make such announcements.
> >
> > *From:* [e-mail] [mailto:[e-mail]]
> > *On Behalf Of *Gregor Schneider
> > *Sent:* 28 November 2009 16:40
> > *To:* ReactOS Development List
> > *Subject:* Re: [ros-dev] Trunk locked
> >
> > Aleksey announced via IRC that trunk is open for commits again.
> >
> > 2009/11/28 Ged Murphy [e-mail]
> >
> > I assume trunk is now unlocked??
> > There's been no mention of it but commits have restarted
> >
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On
> > Behalf Of Aleksey Bragin
> > Sent: 17 November 2009 21:35
> > To: ReactOS Development List
> > Subject: [ros-dev] Trunk locked
> >    Hello,
> >
> > the trunk of our SVN server has been locked to prevent even more
> > regression from entering the tree.
> >
> > So far, after more than 3 weeks after I filed the bug report and not
> > including all previous time when people were complaining about rapps
> > which can't download anything at all - either hangs or crashes, I see
> > that now even PCNet network card is being recognized in my VMWare
> > Workstation 6.5.
> >
> > Trunk is writable right now by members of the bugfix team only,
> > that's so far Cameron (because he is the one supposed to fix
> > networking) and me. If someone volunteers to fix any of the existing
> > regressions, please let me know on irc/email, I'll include you into
> > the bugfix team.
> >
> > Thanks for understanding, and patience. My patience is over.
> >
> > WBR,
> > Aleksey Bragin.
> >
> > Ros-dev mailing list
> > [e-mail]
> > http://www.reactos.org/mailman/listinfo/ros-dev
> >
> > Ros-dev mailing list
> > [e-mail]
> > http://www.reactos.org/mailman/listinfo/ros-dev
> >
> > Ros-dev mailing list
> > [e-mail]
> > http://www.reactos.org/mailman/listinfo/ros-dev
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[Colin Finck]

Zachary Gorden wrote:
> This is common practice before a release and has been done for at least
> the last year or so.

You make it sound like locking the whole trunk and making the majority of
developers unable to work properly is a state we want to keep.
Of course, this has mostly been done due to having no alternatives when
using Subversion and our urgent need to fix these blockers. But still, it's
generally the worst possible action I can think of when it comes to
collaborating on Open-Source projects...

... which raises the question about switching to a distributed version
control system for me again.

While Subversion has proven to be a viable solution for most of our needs,
we still have to cope with its drawbacks from time to time.
The major ones I can think of include:

* Build breakages in trunk prevent other developers from working.

Although some devs might have already get used to occasional build
    breaks, this could become a bigger problem when, for example, two
    developers constantly commit to a common component and update their
    working copies afterwards.
    They would immediately be forced to stop their work and wait for a fix,
    when a build break occurs, even if it's lying in a completely different
    component.

With Git or Mercurial, we could make wholly different workflows
    possible here. A better one might be that each developer only works on
    their own branches (which can be local and/or remote).
    Optionally, two or more developers working on the same component could
    also commit to a common branch, but still independent of the trunk or
    master branch. If one needs stuff from a different branch, he can
    easily merge single commits or fetch all changes from a branch.

Though SVN of course also provides branches, merging is far away from
    being a transparent and trivial task there. I guess that the devs, who
    often deal with our SVN branches, can confirm this.
    Git or Mercurial solve this task way better.

* Not all commits in trunk are well-tested and easily make it unstable.

The recent locking of trunk again showed that it's still a place where
    every trusted dev can, roughly speaking, commit whatever he wants.
    It should be obvious that this leads to unexpected problems from time
    to time.
    Many people might also well remember the GL case, when the drastic
    action of limiting one developer's SVN write access to branches was
    done to prevent him from committing possibly problematic stuff to
    trunk.

Using the branch workflow as described above would circumvent both
    problems and even make trunk an unattractive place to work on.
    If people have their own branches, where they can do everything they
    want, to prepare a big change (e.g. that network locking rewrite),
    nobody should ever need to work directly on trunk again.
    We would just need to establish new rules or methods to get commits
    from the branches into the trunk/master branch. Maybe a combination of
    automatic and manual testing (depending on the situation) can help us
    here.

Such problems will turn out to be more severe with the raising number of
developers.

While this topic has already been partly discussed last year, the
comfortable Windows support (= TortoiseSVN-like shell extensions) for both
Git and Mercurial was still in very early stages of development at that
time.
This situation has improved much in the meantime. TortoiseGit and
TortoiseHg should both provide most of the functions we need.

The differences between Git&TortoiseGit and Mercurial&TortoiseHg lie more
in the general concepts.

As Git was designed with Unix principles in mind, it shares its
one-tool-for-every-task approach. This way, it includes over 100 individual
tools today to somehow solve every task and workflow. The official version
also does not support Windows, but as msysgit and TortoiseGit exist today,
this should be negligible. TortoiseGit is directly based on the TortoiseSVN
source, so you should find it pretty easy to use.

Mercurial was designed with more usability and interoperability in mind, so
it's properly supported under all major platforms. Compared to Git, it only
supports the most common commands.
On the other hand, its TortoiseHg was designed the same way, meaning that
it's a GTK application targeted to run under several platforms as well.
Therefore the user interface is quite different to that of TortoiseSVN.

After this rather long mail, I hope that we can eventually come to a
conclusion about which distributed version control system to choose. Our
existing Git mirror should be suitable for evaluating Git and I'm also
doing a local import of the SVN repository into Mercurial right now (yes,
it seems to work this time).

By the way, we can still maintain a SVN backend for the trunk/master branch
afterwards, so that people may still read the repository the same way
as they have done before.

Best regards,

Colin

[Sir Gallantmon]

On Sat, Nov 28, 2009 at 9:08 PM, Colin Finck [e-mail] wrote:
> Zachary Gorden wrote:
> > This is common practice before a release and has been done for at least
> > the last year or so.
>
> You make it sound like locking the whole trunk and making the majority of
> developers unable to work properly is a state we want to keep.
> Of course, this has mostly been done due to having no alternatives when
> using Subversion and our urgent need to fix these blockers. But still, it's
> generally the worst possible action I can think of when it comes to
> collaborating on Open-Source projects...
>
> ... which raises the question about switching to a distributed version
> control system for me again.
>
> While Subversion has proven to be a viable solution for most of our needs,
> we still have to cope with its drawbacks from time to time.
> The major ones I can think of include:
>
> Build breakages in trunk prevent other developers from working.
>
> Although some devs might have already get used to occasional build
> breaks, this could become a bigger problem when, for example, two
> developers constantly commit to a common component and update their
> working copies afterwards.
> They would immediately be forced to stop their work and wait for a fix,
> when a build break occurs, even if it's lying in a completely different
> component.
>
> With Git or Mercurial, we could make wholly different workflows
> possible here. A better one might be that each developer only works on
> their own branches (which can be local and/or remote).
> Optionally, two or more developers working on the same component could
> also commit to a common branch, but still independent of the trunk or
> master branch. If one needs stuff from a different branch, he can
> easily merge single commits or fetch all changes from a branch.
>
> Though SVN of course also provides branches, merging is far away from
> being a transparent and trivial task there. I guess that the devs, who
> often deal with our SVN branches, can confirm this.
> Git or Mercurial solve this task way better.
>
> Not all commits in trunk are well-tested and easily make it unstable.
>
> The recent locking of trunk again showed that it's still a place where
> every trusted dev can, roughly speaking, commit whatever he wants.
> It should be obvious that this leads to unexpected problems from time
> to time.
> Many people might also well remember the GL case, when the drastic
> action of limiting one developer's SVN write access to branches was
> done to prevent him from committing possibly problematic stuff to
> trunk.
>
> Using the branch workflow as described above would circumvent both
> problems and even make trunk an unattractive place to work on.
> If people have their own branches, where they can do everything they
> want, to prepare a big change (e.g. that network locking rewrite),
> nobody should ever need to work directly on trunk again.
> We would just need to establish new rules or methods to get commits
> from the branches into the trunk/master branch. Maybe a combination of
> automatic and manual testing (depending on the situation) can help us
> here.
>
> Such problems will turn out to be more severe with the raising number of
> developers.
>
> While this topic has already been partly discussed last year, the
> comfortable Windows support (= TortoiseSVN-like shell extensions) for both
> Git and Mercurial was still in very early stages of development at that
> time.
> This situation has improved much in the meantime. TortoiseGit and
> TortoiseHg should both provide most of the functions we need.
>
> The differences between Git&TortoiseGit and Mercurial&TortoiseHg lie more
> in the general concepts.
>
> As Git was designed with Unix principles in mind, it shares its
> one-tool-for-every-task approach. This way, it includes over 100 individual
> tools today to somehow solve every task and workflow. The official version
> also does not support Windows, but as msysgit and TortoiseGit exist today,
> this should be negligible. TortoiseGit is directly based on the TortoiseSVN
> source, so you should find it pretty easy to use.
>
> Mercurial was designed with more usability and interoperability in mind, so
> it's properly supported under all major platforms. Compared to Git, it only
> supports the most common commands.
> On the other hand, its TortoiseHg was designed the same way, meaning that
> it's a GTK application targeted to run under several platforms as well.
> Therefore the user interface is quite different to that of TortoiseSVN.
>
> After this rather long mail, I hope that we can eventually come to a
> conclusion about which distributed version control system to choose. Our
> existing Git mirror should be suitable for evaluating Git and I'm also
> doing a local import of the SVN repository into Mercurial right now (yes,
> it seems to work this time).
>
> By the way, we can still maintain a SVN backend for the trunk/master branch
> afterwards, so that people may still read the repository the same way
> as they have done before.
>
> Best regards,
>
> Colin

I have always found msysgit to be unusually slow in handling
checkouts/branching. Of course, given what MSYS really is, that really isn't
a surprise to me (MSYS is a fork of a really old version of Cygwin, 1.3.3 I
believe).

And while TortoiseGit is similar to TortoiseSVN, my experience with it has
led me to believe it is slower than its SVN counterpart.

TortoiseHG does work, but overall, I don't like using shell extensions, and
I haven't really used TortoiseHG recently since I got my new x64 Windows
desktop computer. It seems okay, but it looks sort of ugly on Vista and
higher thanks to the fact that GTK+ doesn't really render widgets on that
platform very well.

Mercurial itself, though, is very pleasant to use. I use it all the time for
my projects, and I feel that it would work well for ReactOS.

[Timo Kreuzer]

Hi,

I worked with TortoiseHg some time, I thought I could get used to it,
but to no avail.
> From my experience, I can only say that almost *everything* is non

trivial or doesn't work Apart from the shitty interface.
I just tested the latest version again, it's completely unintuitive, and
merging gave me even more conflicts than I would have expected with SVN.

My experience with using a branch with TSVN is that there's no problem.
Even merging hundreds of revisions from trunk to the branch worked quite
well with rarely any conflicts and it's done with a few clicks.

We don't need a different versioning system, we need a better source
organisation. Independency of modules. Independency from the tools/sdk.
That would also help with working on branches.

Just my 2 cents,
Timo

[Aleksey Bragin]

I have to agree that the DVCS I tried (Hg and Git) all are quite...  
let's be honest: crappy (on Windows). I also tried to work on my own  
branches using git, I tried to do Wine syncs using a special Wine  
branch in a local git repo. All failed, everything was non trivial,  
and required a lot more work.

Subversion just works. Also, a git mirror is provided, so that when  
the trunk is locked for some reason, devs still have an option to:
a) create their own branch in SVN, work in a branch, do anything they  
like
b) create their own git fork, work in it, publish it, get famous/ 
blamed, anything they like

There are no restrictions really, especially having in mind that our  
SVN repo is already clonable by everyone, so everyone can have 10+  
years of ReactOS hard work on a DVD disk.

I don't really see any need to switch our VCS to anything else.

WBR,
Aleksey Bragin.

On Nov 29, 2009, at 1:49 PM, Timo Kreuzer wrote:
> Hi,
>
> I worked with TortoiseHg some time, I thought I could get used to it,
> but to no avail.
> From my experience, I can only say that almost *everything* is non
> trivial or doesn't work Apart from the shitty interface.
> I just tested the latest version again, it's completely  
> unintuitive, and
> merging gave me even more conflicts than I would have expected with  
> SVN.
>
> My experience with using a branch with TSVN is that there's no  
> problem.
> Even merging hundreds of revisions from trunk to the branch worked  
> quite
> well with rarely any conflicts and it's done with a few clicks.
>
> We don't need a different versioning system, we need a better source
> organisation. Independency of modules. Independency from the tools/ 
> sdk.
> That would also help with working on branches.
>
> Just my 2 cents,
> Timo
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[Gregor Schneider]

I had similar ideas recently. Working with tortoisegit on Wine for one of my
patches felt weird first, but being able to commit changes locally and is
quite powerful. At first I wondered what it could be good for, but the
locked trunk showed me just that.

Keeping a history of patches which include commit messages and which even
might work separated from others is awesome.
Concerning the tortoiseGit GUI I have to agree that it's not as intuitive as
the SVN counterpart, but one always needs a certain time to get used to new
tools.

Big problem with those systems is the final checkin into the master branch.
The one person managing patch mails and applying all patches has the most
boring job ever. Furthermore this person has to have A LOT of time. No clue
which other concepts are supported by those two tools.

I remember seeing a GIT presentation by Torvalds at some Google event where
he introduced the Linux kernel "team" organisation.
Several maintainers who get patches for their area and himself being the
bigboss just copying their repos and not doing any patches at all. When a
checkout from a maintainer failed for him he just dropped it and took
anotherone.

Pretty cool tree like structure sounds possible here, but the concept of
maintainers or rather development areas/teams doesn't seem to work for
ReactOS. From the time when I started following ReactOS I proposed it
severeal times, but noone seems to be interested.

Gregor

2009/11/29 Colin Finck [e-mail]
> Zachary Gorden wrote:
> > This is common practice before a release and has been done for at least
> > the last year or so.
>
> You make it sound like locking the whole trunk and making the majority of
> developers unable to work properly is a state we want to keep.
> Of course, this has mostly been done due to having no alternatives when
> using Subversion and our urgent need to fix these blockers. But still, it's
> generally the worst possible action I can think of when it comes to
> collaborating on Open-Source projects...
>
> ... which raises the question about switching to a distributed version
> control system for me again.
>
> While Subversion has proven to be a viable solution for most of our needs,
> we still have to cope with its drawbacks from time to time.
> The major ones I can think of include:
>
> Build breakages in trunk prevent other developers from working.
>
> Although some devs might have already get used to occasional build
> breaks, this could become a bigger problem when, for example, two
> developers constantly commit to a common component and update their
> working copies afterwards.
> They would immediately be forced to stop their work and wait for a fix,
> when a build break occurs, even if it's lying in a completely different
> component.
>
> With Git or Mercurial, we could make wholly different workflows
> possible here. A better one might be that each developer only works on
> their own branches (which can be local and/or remote).
> Optionally, two or more developers working on the same component could
> also commit to a common branch, but still independent of the trunk or
> master branch. If one needs stuff from a different branch, he can
> easily merge single commits or fetch all changes from a branch.
>
> Though SVN of course also provides branches, merging is far away from
> being a transparent and trivial task there. I guess that the devs, who
> often deal with our SVN branches, can confirm this.
> Git or Mercurial solve this task way better.
>
> Not all commits in trunk are well-tested and easily make it unstable.
>
> The recent locking of trunk again showed that it's still a place where
> every trusted dev can, roughly speaking, commit whatever he wants.
> It should be obvious that this leads to unexpected problems from time
> to time.
> Many people might also well remember the GL case, when the drastic
> action of limiting one developer's SVN write access to branches was
> done to prevent him from committing possibly problematic stuff to
> trunk.
>
> Using the branch workflow as described above would circumvent both
> problems and even make trunk an unattractive place to work on.
> If people have their own branches, where they can do everything they
> want, to prepare a big change (e.g. that network locking rewrite),
> nobody should ever need to work directly on trunk again.
> We would just need to establish new rules or methods to get commits
> from the branches into the trunk/master branch. Maybe a combination of
> automatic and manual testing (depending on the situation) can help us
> here.
>
> Such problems will turn out to be more severe with the raising number of
> developers.
>
> While this topic has already been partly discussed last year, the
> comfortable Windows support (= TortoiseSVN-like shell extensions) for both
> Git and Mercurial was still in very early stages of development at that
> time.
> This situation has improved much in the meantime. TortoiseGit and
> TortoiseHg should both provide most of the functions we need.
>
> The differences between Git&TortoiseGit and Mercurial&TortoiseHg lie more
> in the general concepts.
>
> As Git was designed with Unix principles in mind, it shares its
> one-tool-for-every-task approach. This way, it includes over 100 individual
> tools today to somehow solve every task and workflow. The official version
> also does not support Windows, but as msysgit and TortoiseGit exist today,
> this should be negligible. TortoiseGit is directly based on the TortoiseSVN
> source, so you should find it pretty easy to use.
>
> Mercurial was designed with more usability and interoperability in mind, so
> it's properly supported under all major platforms. Compared to Git, it only
> supports the most common commands.
> On the other hand, its TortoiseHg was designed the same way, meaning that
> it's a GTK application targeted to run under several platforms as well.
> Therefore the user interface is quite different to that of TortoiseSVN.
>
> After this rather long mail, I hope that we can eventually come to a
> conclusion about which distributed version control system to choose. Our
> existing Git mirror should be suitable for evaluating Git and I'm also
> doing a local import of the SVN repository into Mercurial right now (yes,
> it seems to work this time).
>
> By the way, we can still maintain a SVN backend for the trunk/master branch
> afterwards, so that people may still read the repository the same way
> as they have done before.
>
> Best regards,
>
> Colin
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[Aleksey Bragin]

You all are so impatient that I couldn't even have had supper between  
I unlocked trunk and the moment of posting about this to the mailing  
list :)

Now, trunk is unlocked since last two major problems are solved:
1. Network is unegressed by reverting oskit locking rewrite. Despite  
it's a good thing, unfortunately it's buggy and finding this bug  
turned out to be non-trivial.
2. Uniata still needs higher delays (in VirtualBox), so we are going  
to fine tune it with Olaf or Gabriel who experience this problem and  
commit the result in trunk / merge to 0.3.11 branch.

0.3.11 release has been branched now, it's going to include a few  
more merges from trunk (the above), then a prerelease iso is going to  
be prepared by Colin and tested by Victor Martinez & co, after that  
we should release.

All of this (most of it) should (must) happen before ~Wednesday of  
next week, because I may not be available on wednesday and thursday.  
Don't forget changelogs!

WBR,
Aleksey Bragin.

On Nov 28, 2009, at 8:06 PM, Ged Murphy wrote:
> You’re probably all sick of me saying this (as I am saying it), but  
> IRC is the wrong place to make such announcements.
>
> From: [e-mail] [mailto:ros-dev- 
> [e-mail]] On Behalf Of Gregor Schneider
> Sent: 28 November 2009 16:40
> To: ReactOS Development List
> Subject: Re: [ros-dev] Trunk locked
>
> Aleksey announced via IRC that trunk is open for commits again.
>
> 2009/11/28 Ged Murphy [e-mail]
>
> I assume trunk is now unlocked??
> There's been no mention of it but commits have restarted
>
> -----Original Message-----
> From: [e-mail] [mailto:ros-dev- 
> [e-mail]] On
> Behalf Of Aleksey Bragin
> Sent: 17 November 2009 21:35
> To: ReactOS Development List
> Subject: [ros-dev] Trunk locked
>    Hello,
>
> the trunk of our SVN server has been locked to prevent even more
> regression from entering the tree.
>
> So far, after more than 3 weeks after I filed the bug report and not
> including all previous time when people were complaining about rapps
> which can't download anything at all - either hangs or crashes, I see
> that now even PCNet network card is being recognized in my VMWare
> Workstation 6.5.
>
> Trunk is writable right now by members of the bugfix team only,
> that's so far Cameron (because he is the one supposed to fix
> networking) and me. If someone volunteers to fix any of the existing
> regressions, please let me know on irc/email, I'll include you into
> the bugfix team.
>
> Thanks for understanding, and patience. My patience is over.
>
> WBR,
> Aleksey Bragin.

[James Tabor]

Hi,
I've tested FF 3.5 and Seamonkey 2.0 with the patch from Bug 4100,
other than ugly alphanumeric issues, it works and should be added to
head and merged into 0.3.11.

Thanks,
James

Ref:
http://www.reactos.org/bugzilla/show_bug.cgi?id=4100

On Sat, Nov 28, 2009 at 1:54 PM, Aleksey Bragin [e-mail] wrote:
> You all are so impatient that I couldn't even have had supper between I
> unlocked trunk and the moment of posting about this to the mailing list :)
> Now, trunk is unlocked since last two major problems are solved:
> Network is unegressed by reverting oskit locking rewrite. Despite it's a
>
> good thing, unfortunately it's buggy and finding this bug turned out to be
> non-trivial.
> 2. Uniata still needs higher delays (in VirtualBox), so we are going to fine
> tune it with Olaf or Gabriel who experience this problem and commit the
> result in trunk / merge to 0.3.11 branch.
> 0.3.11 release has been branched now, it's going to include a few more
> merges from trunk (the above), then a prerelease iso is going to be prepared
> by Colin and tested by Victor Martinez & co, after that we should release.
> All of this (most of it) should (must) happen before ~Wednesday of next
> week, because I may not be available on wednesday and thursday. Don't forget
> changelogs!
>
> WBR,
> Aleksey Bragin.