Cache / Memory Manager / FileSystemDrivers

[Aleksey Bragin]

	Hello,
I recently spent some time experimenting with various Cc rewrites we  
have in our tree, and before that I extensively tested our fastfat  
driver in a real NT environment (MS Windows 2003).

The conclusion of the above work is that our fastfat driver either  
needs serious bugfixing, or a rewrite is needed. It corrupts  
directory tables in a real NT, leads to unusual behaviour of cc- 
rewrite branch, and may have side effects on arty's newcc.

Before this is done (bugfixing or rewriting, developing and testing  
against a Windows 2003 at least, not ReactOS), it's meaningless to  
continue any other work on Cc and related Mm parts.


WBR,
Aleksey Bragin.

[WaxDragon]

On Wed, Jan 7, 2009 at 9:18 AM, Aleksey Bragin <aleksey(a)reactos.org> wrote:
>          Hello,
>  I recently spent some time experimenting with various Cc rewrites we
>  have in our tree, and before that I extensively tested our fastfat
>  driver in a real NT environment (MS Windows 2003).
>
>  The conclusion of the above work is that our fastfat driver either
>  needs serious bugfixing, or a rewrite is needed. It corrupts
>  directory tables in a real NT, leads to unusual behaviour of cc-
>  rewrite branch, and may have side effects on arty's newcc.
>
>  Before this is done (bugfixing or rewriting, developing and testing
>  against a Windows 2003 at least, not ReactOS), it's meaningless to
>  continue any other work on Cc and related Mm parts.
>
>
>  WBR,
>  Aleksey Bragin.
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>  
Let's make a plan!  I want a proper branch for the cc rewrites.  I'd
like to have a live branch, not this half branch, half patch form that
cc_rewrite is in now.  Perhaps this would be a good place for the
working fastfat to be dropped when finished.

I have time and resources that I could put towards this goal.  Let's
get fastfat working on 2k3, then drop it into a new cc branch and get
it working..

<Leroy Jenkins>LET'S DO THIS, CHUMS!</Leroy Jenkins>

WD
-- 
<+encoded> if you square a unicorn do you get a real animal?

[Aleksey Bragin]

On Jan 7, 2009, at 7:24 PM, WaxDragon wrote:

>   On Wed, Jan 7, 2009 at 9:18 AM, Aleksey Bragin  
>  <aleksey(a)reactos.org> wrote:
> >          Hello,
> >  I recently spent some time experimenting with various Cc rewrites we
> >  have in our tree, and before that I extensively tested our fastfat
> >  driver in a real NT environment (MS Windows 2003).
> >
> >  The conclusion of the above work is that our fastfat driver either
> >  needs serious bugfixing, or a rewrite is needed. It corrupts
> >  directory tables in a real NT, leads to unusual behaviour of cc-
> >  rewrite branch, and may have side effects on arty's newcc.
> >
> >  Before this is done (bugfixing or rewriting, developing and testing
> >  against a Windows 2003 at least, not ReactOS), it's meaningless to
> >  continue any other work on Cc and related Mm parts.
> >
> >
> >  WBR,
> >  Aleksey Bragin. 
>  Let's make a plan!  I want a proper branch for the cc rewrites.  I'd
>  like to have a live branch, not this half branch, half patch form that
>  cc_rewrite is in now.  Perhaps this would be a good place for the
>  working fastfat to be dropped when finished.
>
>  I have time and resources that I could put towards this goal.  Let's
>  get fastfat working on 2k3, then drop it into a new cc branch and get
>  it working..
>
>  <Leroy Jenkins>LET'S DO THIS, CHUMS!</Leroy Jenkins>
>
>  WD 
Live branch needs constant merging. Have a look at amd64 bringup  
branch: most of commits are merges. That mm.patch is an ugly way of  
keeping the branch always uptodate...

Anyway, I have made some fixes to the branch, so if someone wants to  
test, I would need to commit my changes.

As for the fastfat, I think the problems is in synchronization  
somewhere, not in a pool corruption, passing invalid parameters,  
misusing Cc API, or anything like that - I fixed that already.

Another idea was to take ext2fsd by Matt Wu, which is supposed to  
work, and convert it to a fat32/16/12 driver.

[Alex Ionescu]

The WDK ships with a working windows 2003 fat driver... rewrite it based on
that one.
Best regards,
Alex Ionescu


On Wed, Jan 7, 2009 at 12:04 PM, Aleksey Bragin <aleksey(a)reactos.org> wrote:

>   On Jan 7, 2009, at 7:24 PM, WaxDragon wrote:
>
> >   On Wed, Jan 7, 2009 at 9:18 AM, Aleksey Bragin
> >  <aleksey(a)reactos.org> wrote:
> > >          Hello,
> > >  I recently spent some time experimenting with various Cc rewrites we
> > >  have in our tree, and before that I extensively tested our fastfat
> > >  driver in a real NT environment (MS Windows 2003).
> > >
> > >  The conclusion of the above work is that our fastfat driver either
> > >  needs serious bugfixing, or a rewrite is needed. It corrupts
> > >  directory tables in a real NT, leads to unusual behaviour of cc-
> > >  rewrite branch, and may have side effects on arty's newcc.
> > >
> > >  Before this is done (bugfixing or rewriting, developing and testing
> > >  against a Windows 2003 at least, not ReactOS), it's meaningless to
> > >  continue any other work on Cc and related Mm parts.
> > >
> > >
> > >  WBR,
> > >  Aleksey Bragin. 
> >  Let's make a plan!  I want a proper branch for the cc rewrites.  I'd
> >  like to have a live branch, not this half branch, half patch form that
> >  cc_rewrite is in now.  Perhaps this would be a good place for the
> >  working fastfat to be dropped when finished.
> >
> >  I have time and resources that I could put towards this goal.  Let's
> >  get fastfat working on 2k3, then drop it into a new cc branch and get
> >  it working..
> >
> >  <Leroy Jenkins>LET'S DO THIS, CHUMS!</Leroy Jenkins>
> >
> >  WD 
>  Live branch needs constant merging. Have a look at amd64 bringup
>  branch: most of commits are merges. That mm.patch is an ugly way of
>  keeping the branch always uptodate...
>
>  Anyway, I have made some fixes to the branch, so if someone wants to
>  test, I would need to commit my changes.
>
>  As for the fastfat, I think the problems is in synchronization
>  somewhere, not in a pool corruption, passing invalid parameters,
>  misusing Cc API, or anything like that - I fixed that already.
>
>  Another idea was to take ext2fsd by Matt Wu, which is supposed to
>  work, and convert it to a fat32/16/12 driver.
>
>
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>

[Pierre SCHWEITZER]

Hi,
how far can we use it? It must be under Microsoft copyright. Moreover, it must be quite
complete, so it would not be a rewrite, just an importation.
P. Schweitzer

Date: Wed, 7 Jan 2009 13:50:39 -0500
From: ionucu(a)videotron.ca
To: ros-dev(a)reactos.org
Subject: Re: [ros-dev] Cache / Memory Manager / FileSystemDrivers

The WDK ships with a working windows 2003 fat driver... rewrite it based on that one.Best
regards,
Alex Ionescu



On Wed, Jan 7, 2009 at 12:04 PM, Aleksey Bragin <aleksey(a)reactos.org> wrote:

On Jan 7, 2009, at 7:24 PM, WaxDragon wrote:



>   On Wed, Jan 7, 2009 at 9:18 AM, Aleksey Bragin 
>   <aleksey(a)reactos.org> wrote: 
>  >        Hello, 
>  > I recently spent some time experimenting with
> various Cc rewrites we 
>  > have in our tree, and before that I extensively
> tested our fastfat 
>  > driver in a real NT environment (MS Windows 2003).
>  > 
>  > The conclusion of the above work is that our
> fastfat driver either 
>  > needs serious bugfixing, or a rewrite is needed.
> It corrupts 
>  > directory tables in a real NT, leads to unusual
> behaviour of cc- 
>  > rewrite branch, and may have side effects on
> arty's newcc. 
>  > 
>  > Before this is done (bugfixing or rewriting,
> developing and testing 
>  > against a Windows 2003 at least, not ReactOS),
> it's meaningless to 
>  > continue any other work on Cc and related Mm
> parts. 
>  > 
>  > 
>  > WBR, 
>  > Aleksey Bragin. 
>   
>   Let's make a plan!  I want a proper branch for the
> cc rewrites.  I'd 
>   like to have a live branch, not this half branch, half
> patch form that 
>   cc_rewrite is in now.  Perhaps this would be a good
> place for the 
>   working fastfat to be dropped when finished. 
>   
>   I have time and resources that I could put towards
> this goal.  Let's 
>   get fastfat working on 2k3, then drop it into a new cc
> branch and get 
>   it working.. 
>   
> <Leroy Jenkins>LET'S DO THIS, CHUMS!</Leroy Jenkins
>   
>   
>   WD 


Live branch needs constant merging. Have a look at amd64 bringup

branch: most of commits are merges. That mm.patch is an ugly way of

keeping the branch always uptodate...



Anyway, I have made some fixes to the branch, so if someone wants to

test, I would need to commit my changes.



As for the fastfat, I think the problems is in synchronization

somewhere, not in a pool corruption, passing invalid parameters,

misusing Cc API, or anything like that - I fixed that already.



Another idea was to take ext2fsd by Matt Wu, which is supposed to

work, and convert it to a fat32/16/12 driver.





_______________________________________________

Ros-dev mailing list

Ros-dev(a)reactos.org

http://www.reactos.org/mailman/listinfo/ros-dev



_________________________________________________________________
Téléphonez gratuitement à tous vos proches avec Windows Live Messenger  !  Téléchargez-le
maintenant ! 
http://www.windowslive.fr/messenger/1.asp

[Alex Ionescu]

You need to rewrite it to fulfill all the licensing requirements.
Many things in FASTFAT aren't needed for us yet, so in theory (IANAL), even
stripping out those parts and keeping the rest of the driver intact would be
ok -- based on my knowledge that copyright law states that you need to copy
>   70% for it to be considered "the same work",
> anything less than that and 
it's okay (again, IANAL).

So my opinion (IANAL!!!) is that if you use the WDK FASTFAT driver as a
reference source, and write (on your own, not copy pasting) the same
interfaces/function names/data types/structures (which are, by definition,
not copyrightable), and then write your own code (use a different layout,
optimize the functions, use other variables/similar code logic, etc) and
additionally, only implement, for now, say half the driver, you'd be 100%
legal, at least in the US and other countries that signed the WIPO I think
it's called.

Best regards,
Alex Ionescu


2009/1/7 Pierre SCHWEITZER <heis_spiter(a)hotmail.com>

>    Hi,
>  how far can we use it? It must be under Microsoft copyright. Moreover, it
>  must be quite complete, so it would not be a rewrite, just an importation.
>  P. Schweitzer
>
>  ------------------------------
>  Date: Wed, 7 Jan 2009 13:50:39 -0500
>  From: ionucu(a)videotron.ca
>  To: ros-dev(a)reactos.org
>  Subject: Re: [ros-dev] Cache / Memory Manager / FileSystemDrivers
>
>
>  The WDK ships with a working windows 2003 fat driver... rewrite it based on
>  that one.
>  Best regards,
>  Alex Ionescu
>
>
>  On Wed, Jan 7, 2009 at 12:04 PM, Aleksey Bragin <aleksey(a)reactos.org>wrote;wrote:
>
>  On Jan 7, 2009, at 7:24 PM, WaxDragon wrote:
>
> >   On Wed, Jan 7, 2009 at 9:18 AM, Aleksey Bragin
> >  <aleksey(a)reactos.org> wrote:
> > >          Hello,
> > >  I recently spent some time experimenting with various Cc rewrites we
> > >  have in our tree, and before that I extensively tested our fastfat
> > >  driver in a real NT environment (MS Windows 2003).
> > >
> > >  The conclusion of the above work is that our fastfat driver either
> > >  needs serious bugfixing, or a rewrite is needed. It corrupts
> > >  directory tables in a real NT, leads to unusual behaviour of cc-
> > >  rewrite branch, and may have side effects on arty's newcc.
> > >
> > >  Before this is done (bugfixing or rewriting, developing and testing
> > >  against a Windows 2003 at least, not ReactOS), it's meaningless to
> > >  continue any other work on Cc and related Mm parts.
> > >
> > >
> > >  WBR,
> > >  Aleksey Bragin. 
> >  Let's make a plan!  I want a proper branch for the cc rewrites.  I'd
> >  like to have a live branch, not this half branch, half patch form that
> >  cc_rewrite is in now.  Perhaps this would be a good place for the
> >  working fastfat to be dropped when finished.
> >
> >  I have time and resources that I could put towards this goal.  Let's
> >  get fastfat working on 2k3, then drop it into a new cc branch and get
> >  it working..
> >
> >  <Leroy Jenkins>LET'S DO THIS, CHUMS!</Leroy Jenkins>
> >
> >  WD 
>  Live branch needs constant merging. Have a look at amd64 bringup
>  branch: most of commits are merges. That mm.patch is an ugly way of
>  keeping the branch always uptodate...
>
>  Anyway, I have made some fixes to the branch, so if someone wants to
>  test, I would need to commit my changes.
>
>  As for the fastfat, I think the problems is in synchronization
>  somewhere, not in a pool corruption, passing invalid parameters,
>  misusing Cc API, or anything like that - I fixed that already.
>
>  Another idea was to take ext2fsd by Matt Wu, which is supposed to
>  work, and convert it to a fat32/16/12 driver.
>
>
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>
>
>
>  ------------------------------
>  Discutez sur Messenger où que vous soyez ! Mettez Messenger sur votre
>  mobile ! <http://www.messengersurvotremobile.com/>
>
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>
>

[Aleksey Bragin]

It might be possible to reuse parts of existing vfat driver routines  
(which there is no doubt about correctness).

Anyone objects to such approach (a real *rewrite* of a driver, not  
just porting WDK's fastfat sample)? If noone, I consider this a way  
to go.


WBR,
Aleksey.

On Jan 7, 2009, at 11:13 PM, Alex Ionescu wrote:

>   You need to rewrite it to fulfill all the licensing
> requirements.
>
>  Many things in FASTFAT aren't needed for us yet, so in theory  
>  (IANAL), even stripping out those parts and keeping the rest of the  
>  driver intact would be ok -- based on my knowledge that copyright  
>  law states that you need to copy > 70% for it to be considered "the  
>  same work", anything less than that and it's okay (again, IANAL).
>
>  So my opinion (IANAL!!!) is that if you use the WDK FASTFAT driver  
>  as a reference source, and write (on your own, not copy pasting)  
>  the same interfaces/function names/data types/structures (which  
>  are, by definition, not copyrightable), and then write your own  
>  code (use a different layout, optimize the functions, use other  
>  variables/similar code logic, etc) and additionally, only  
>  implement, for now, say half the driver, you'd be 100% legal, at  
>  least in the US and other countries that signed the WIPO I think  
>  it's called.
>
>  Best regards,
>  Alex Ionescu
>

[art yerkes]

On Wed, 7 Jan 2009 20:04:34 +0300
Aleksey Bragin <aleksey(a)reactos.org> wrote:

>   On Jan 7, 2009, at 7:24 PM, WaxDragon wrote:
>  
> >   On Wed, Jan 7, 2009 at 9:18 AM, Aleksey Bragin  
> >  <aleksey(a)reactos.org> wrote:
> > >          Hello,
> > >  I recently spent some time experimenting with various Cc rewrites we
> > >  have in our tree, and before that I extensively tested our fastfat
> > >  driver in a real NT environment (MS Windows 2003).
> > >
> > >  The conclusion of the above work is that our fastfat driver either
> > >  needs serious bugfixing, or a rewrite is needed. It corrupts
> > >  directory tables in a real NT, leads to unusual behaviour of cc-
> > >  rewrite branch, and may have side effects on arty's newcc.
> > >
> > >  Before this is done (bugfixing or rewriting, developing and testing
> > >  against a Windows 2003 at least, not ReactOS), it's meaningless to
> > >  continue any other work on Cc and related Mm parts.
> > >
> > >
> > >  WBR,
> > >  Aleksey Bragin. 
> >  Let's make a plan!  I want a proper branch for the cc rewrites.  I'd
> >  like to have a live branch, not this half branch, half patch form that
> >  cc_rewrite is in now.  Perhaps this would be a good place for the
> >  working fastfat to be dropped when finished.
> >
> >  I have time and resources that I could put towards this goal.  Let's
> >  get fastfat working on 2k3, then drop it into a new cc branch and get
> >  it working..
> >
> >  <Leroy Jenkins>LET'S DO THIS, CHUMS!</Leroy Jenkins>
> >
> >  WD 
>  
>  Live branch needs constant merging. Have a look at amd64 bringup  
>  branch: most of commits are merges. That mm.patch is an ugly way of  
>  keeping the branch always uptodate...
>  
>  Anyway, I have made some fixes to the branch, so if someone wants to  
>  test, I would need to commit my changes.
>  
>  As for the fastfat, I think the problems is in synchronization  
>  somewhere, not in a pool corruption, passing invalid parameters,  
>  misusing Cc API, or anything like that - I fixed that already.
>  
>  Another idea was to take ext2fsd by Matt Wu, which is supposed to  
>  work, and convert it to a fat32/16/12 driver. 
I've been working on some things under git over svn.  Merging trunk
has been pretty easy this way, although some assembly was required.
Perhaps rather than switching, we can start a git repository just
for branches and feed it from svn, also using it to build diffs for
merging back to trunk.
-- 
art yerkes &lt;ayerkes(a)speakeasy.net&gt;

[Ged]

Aleksey Bragin wrote:

>   Live branch needs constant merging. Have a look at
> amd64 bringup  
>  branch: most of commits are merges. That mm.patch is an ugly way of  
>  keeping the branch always uptodate... 

This is the reason all my branches are now local (and my lack of commits,
making it look like I do nothing anymore)
It was a great idea until my laptop was stolen and I lost all my code ....

Strange that this just popped up as Timo and I were only talking about this
the other day :

<Physicus>	atm I'm fine with SVN for reactos. What i would wish to have
was some kind of "virtual branch" or "intermediate branch" something
between
trunk and your local copy where you can commit to and that does receive
commits from trunk. So it stays in sync with trunk.
<Physicus>	Both a remote and a local solution would be great
<GedMurphy>	that's the exact reason I don't use branches
<Physicus>	the sync mess
<GedMurphy>	yeah, too much hard work and lost time
<GedMurphy>	I have about 5 local branches instead
<GedMurphy>	it worked fine, until my laptop was stolen and I lost all my
code ... lol
<GedMurphy>	although, I've recreated most of my old branches over the
Christmas period, so I obviously don't learn ;)
<Physicus>	That's what my idea is about. You create an intermediate
branch (either locally or on a remote server) then checkout a local copy.
Your commits go to that intermediate branch, but commits to trunk do also go
there. If there's a conflict, you need to resolve it as normally when
working directly with trunk
<GedMurphy>	that would be perfect
<Physicus>	Make svn people implement something like that and we might
get people working on branches

[Alex Ionescu]

One word: Mercurial.
Steven, pitch in and back me up.

Best regards,
Alex Ionescu


On Thu, Jan 8, 2009 at 5:48 AM, Ged <gedmurphy(a)gmail.com> wrote:

>   Aleksey Bragin wrote:
>
> >   Live branch needs constant merging. Have a look
> > at amd64 bringup
> >  branch: most of commits are merges. That mm.patch is an ugly way of
> >  keeping the branch always uptodate... 
>
>  This is the reason all my branches are now local (and my lack of commits,
>  making it look like I do nothing anymore)
>  It was a great idea until my laptop was stolen and I lost all my code ....
>
>  Strange that this just popped up as Timo and I were only talking about this
>  the other day :
>
>  <Physicus>      atm I'm fine with SVN for reactos. What i would wish to
>  have
>  was some kind of "virtual branch" or "intermediate branch" something
>  between
>  trunk and your local copy where you can commit to and that does receive
>  commits from trunk. So it stays in sync with trunk.
>  <Physicus>      Both a remote and a local solution would be great
>  <GedMurphy>     that's the exact reason I don't use branches
>  <Physicus>      the sync mess
>  <GedMurphy>     yeah, too much hard work and lost time
>  <GedMurphy>     I have about 5 local branches instead
>  <GedMurphy>     it worked fine, until my laptop was stolen and I lost all
>  my
>  code ... lol
>  <GedMurphy>     although, I've recreated most of my old branches over the
>  Christmas period, so I obviously don't learn ;)
>  <Physicus>      That's what my idea is about. You create an intermediate
>  branch (either locally or on a remote server) then checkout a local copy.
>  Your commits go to that intermediate branch, but commits to trunk do also
>  go
>  there. If there's a conflict, you need to resolve it as normally when
>  working directly with trunk
>  <GedMurphy>     that would be perfect
>  <Physicus>      Make svn people implement something like that and we might
>  get people working on branches
>
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>

[Colin Finck]

One word: Buggy
 
Both Aleksey and me already tried to convert our SVN repository to Hg, but
it failed all the time. Aleksey even tried it recently again before starting
this GIT mirror.
More information at http://www.selenic.com/mercurial/bts/issue1197
 
Best regards,
 
Colin
 



  _____  

From: ros-dev-bounces(a)reactos.org [mailto:[e-mail]] On
Behalf Of Alex Ionescu
Sent: Thursday, January 08, 2009 8:35 PM
To: ReactOS Development List
Subject: Re: [ros-dev] Cache / Memory Manager / FileSystemDrivers


One word: Mercurial. 

Steven, pitch in and back me up.


Best regards,
Alex Ionescu



On Thu, Jan 8, 2009 at 5:48 AM, Ged <gedmurphy(a)gmail.com> wrote:


Aleksey Bragin wrote:

>   Live branch needs constant merging. Have a look at
> amd64 bringup
>  branch: most of commits are merges. That mm.patch is an ugly way of
>  keeping the branch always uptodate... 


This is the reason all my branches are now local (and my lack of commits,
making it look like I do nothing anymore)
It was a great idea until my laptop was stolen and I lost all my code ....

Strange that this just popped up as Timo and I were only talking about this
the other day :

<Physicus>      atm I'm fine with SVN for reactos. What i would wish to have
was some kind of "virtual branch" or "intermediate branch" something
between
trunk and your local copy where you can commit to and that does receive
commits from trunk. So it stays in sync with trunk.
<Physicus>      Both a remote and a local solution would be great
<GedMurphy>     that's the exact reason I don't use branches
<Physicus>      the sync mess
<GedMurphy>     yeah, too much hard work and lost time
<GedMurphy>     I have about 5 local branches instead
<GedMurphy>     it worked fine, until my laptop was stolen and I lost all my
code ... lol
<GedMurphy>     although, I've recreated most of my old branches over the
Christmas period, so I obviously don't learn ;)
<Physicus>      That's what my idea is about. You create an intermediate
branch (either locally or on a remote server) then checkout a local copy.
Your commits go to that intermediate branch, but commits to trunk do also go
there. If there's a conflict, you need to resolve it as normally when
working directly with trunk
<GedMurphy>     that would be perfect
<Physicus>      Make svn people implement something like that and we might
get people working on branches


_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

[Alexander Potashev]

On 14:35 Thu 08 Jan     , Alex Ionescu wrote:
>   One word: Mercurial.
>  Steven, pitch in and back me up. 
But what are the advantages of Mercurial for ReactOS? Wine and many
other projects uses Git...

>   
>  Best regards,
>  Alex Ionescu

[Zachary Gorden]

I actually had a conversion going but a power outage took it out.  It was
however going steadly without problems.

Advantages of Mercurial?  Better Windows support would be a big one.  And
just because Wine and other projects use Git does not mean it is
automatically suited to this project.

On Thu, Jan 8, 2009 at 2:15 PM, Alexander Potashev <aspotashev(a)gmail.com>wrote;wrote:

>   On 14:35 Thu 08 Jan     , Alex Ionescu wrote:
> >   One word: Mercurial.
> >  Steven, pitch in and back me up. 
>  But what are the advantages of Mercurial for ReactOS? Wine and many
>  other projects uses Git...
>
> >  
> >  Best regards,
> >  Alex Ionescu 
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>

[Ged]

GIT is pretty much unusable for us Windows users. It's ugly and clunky and
goes hand in hand with linux.

 

HG is much better alternative, if nothing else other than the tortoise shell
extension we're all so accustomed to with TSVN.

It's a shame it's problematic to move to at the moment.

 

 

From: ros-dev-bounces(a)reactos.org [mailto:[e-mail]] On
Behalf Of Zachary Gorden
Sent: 08 January 2009 20:42
To: ReactOS Development List
Subject: Re: [ros-dev] Cache / Memory Manager / FileSystemDrivers

 

I actually had a conversion going but a power outage took it out.  It was
however going steadly without problems.

Advantages of Mercurial?  Better Windows support would be a big one.  And
just because Wine and other projects use Git does not mean it is
automatically suited to this project.

On Thu, Jan 8, 2009 at 2:15 PM, Alexander Potashev <aspotashev(a)gmail.com>
wrote:

On 14:35 Thu 08 Jan     , Alex Ionescu wrote:
>   One word: Mercurial.
>  Steven, pitch in and back me up. 
But what are the advantages of Mercurial for ReactOS? Wine and many
other projects uses Git...

>  
>  Best regards,
>  Alex Ionescu 

_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

[Aleksey Bragin]

I thought the same before I tried msysgit + TortoiseGit. As for the  
first, core package, msysgit is a native port, and I must say, it  
indeed works well. As for the second, TortoiseGit, it's an in- 
development tool based on TortoiseSVN and is already usable. Yes, it  
lacks many things, "Not yet implemented" messageboxes are quite  
often, but, basic needed operations are there, diff/merger are there,  
and it doesn't look like an abandoned project.

At least, I don't really want to bugfix Mercurial itself if I have a  
working solution with Git under Windows. And many of you know I'm no  
fan of cmd line tools :-)


WBR,
Aleksey.

On Jan 9, 2009, at 12:21 AM, Ged wrote:

>   GIT is pretty much unusable for us Windows users. It’s
> ugly and  
>  clunky and goes hand in hand with linux.
>
>
>
>  HG is much better alternative, if nothing else other than the  
>  tortoise shell extension we’re all so accustomed to with TSVN.
>
>  It’s a shame it’s problematic to move to at the moment.