--- Sam xasmx@optonline.net wrote:
This is a clean room implementation of cards.dll. While it is not really an official windows system dll, it is almost always present, and several applications depend on it.
We have a cards.dll in the ReactOS tree that we wanted to merge with Winehq but the license of the bitmaps was GPL and not LGPL. Do you want to take a look at our implementation and see if there is anything you can use from it?
Thanks Steven
__________________________________ Do you Yahoo!? Yahoo! Mail - More reliable, more storage, less spam http://mail.yahoo.com
On Mon, 15 Mar 2004, Steven Edwards wrote:
We have a cards.dll in the ReactOS tree that we wanted to merge with Winehq but the license of the bitmaps was GPL and not LGPL. Do you want to take a look at our implementation and see if there is anything you can use from it?
Time and again, it seems that the ReactOS folks produce a lot of throw-away code, by keeping it in the ReactOS tree. I've lost count on how many times this happened in the past, don't you guys get it that we should work together on this stuff? I mean, don't you want the work you do to live on, don't you feel sorry for all the wasted effort?
Dimitrie O Paun wrote:
On Mon, 15 Mar 2004, Steven Edwards wrote:
We have a cards.dll in the ReactOS tree that we wanted to merge with Winehq but the license of the bitmaps was GPL and not LGPL. Do you want to take a look at our implementation and see if there is anything you can use from it?
Time and again, it seems that the ReactOS folks produce a lot of throw-away code, by keeping it in the ReactOS tree.
Well to take up for the ReactOS folks.... Martin and Ge have done one hell of a fine job on shell32 !! And they have given every thing back.. Not once but twice! As AJ was on vacation at the time and Martin & Ge spent alot of time i'm sure spliting the patch up into smaller chunks so it would be excepted here.
I've lost count
wholy shit you got to three :) I shall now faint.........
on how many times this happened in the past, don't you guys get it that we should work together on this stuff?
example listed above my friend.
I mean, don't you want
the work you do to live on,
It is in the wine tree.....
don't you feel sorry for all the wasted
effort?
I see these guys as our friends, comrades and they have to my simple knowledge agreed to cross licence *all* there work th the LGPL so *we* not them can use there hard work..... I have yet to hear of a single incidence where *wine* code was cross licensed back to the GPL.... So I say we should work with them! As they have worked with us..... And the only thing you need to do is ask and i'm sure they would cross licence .. And then if you wan't what they have... Guess what???????? You are the one who needs to do the merge!
The only ones that need to feel sorry are the ones under a @#$ AFPL licence. Not the people who believe in the spirit of *free* GNU software.
To sum this up..... *WE* every sigle wine user .... all 100,000 at the last estate should be glad that were in the company of the people at http:www.reactos.com as they are *our* friends & comrades and not someone to flame!!!
I say long live http:www.reactos.com
Tom
aka - Thomas Wickline
P.S.
I think of "Dimitrie O Paun" as a true friend and if he gets mad.... Oh well the truth hurts.
On Mon, 15 Mar 2004, Tom wrote:
To sum this up..... *WE* every sigle wine user .... all 100,000 at the last estate should be glad that were in the company of the people at http:www.reactos.com as they are *our* friends & comrades and not someone to flame!!!
Folks, my applogies, the message wasn't intended as a flame. Nor did I imply that the ReactOS folks don't contribute. As you said, lately they've been doing some very good work on shell32. All I tried to say is that there are instances where things don't get merged soon enough, and work is duplicated. And even if that happens, I wouldn't flame people for it, I just feel bad for the developer that just wasted their time.
But hey, if that's the nature of things, so be it. However, don't consider my previous message a flame -- it wasn't.
Dimitrie O Paun wrote:
Folks, my applogies, the message wasn't intended as a flame.
And my applogies for calling your post a flame when it wasn't. I think were all friends here so... we should have fun and move on.
Sorry Dimi, if i've caused any misunderstandings!
Tom
I'm sorry if this turns out to be a troll. That is not my intention.
Can someone remind me again why we can't have GPL DLLs in the tree? Doesn't the "call through documented interface blah blah blah not derived work" argument cause the license for each two DLLs in Wine to be independant?
Shachar
From: Tom
Well to take up for the ReactOS folks.... Martin and Ge have done one hell of a fine job on shell32 !! And they have given every thing back.. Not once but twice! As AJ was on vacation at the time and Martin & Ge spent alot of time i'm sure spliting the patch up into smaller chunks so it would be excepted here.
For the record, 99% of that was Martins work, not mine.
Ge van Geldorp.
Tom twickline@skybest.com writes:
I see these guys as our friends, comrades and they have to my simple knowledge agreed to cross licence *all* there work th the LGPL so *we* not them can use there hard work..... I have yet to hear of a single incidence where *wine* code was cross licensed back to the GPL....
Every single bit of Wine can be relicensed under the GPL without special permission, that's explicitly allowed by the LGPL.
--- "Dimitrie O. Paun" dimi@intelliware.ca wrote:
Time and again, it seems that the ReactOS folks produce a lot of throw-away code, by keeping it in the ReactOS tree. I've lost count on how many times this happened in the past, don't you guys get it that we should work together on this stuff? I mean, don't you want the work you do to live on, don't you feel sorry for all the wasted effort?
I would agree with that except for the fact that we could not submit the code as it was. The resources were GPL not LGPL. The author of the code (Filip Navara) sends patches to Winehq all the time so its not like he doesnt share with Winehq. In this case though he was not the author of the resources. Count the number of patches submitted by Filip, Martin, Ge and myself, plus the orginal code we have released under LGPL/GPL. We maybe have a 10% drop/duplication rate.
We have some developers that sometimes like to start working on something only to drop it later on due to losing interest. Uxtheme is a good example of this. We had the start of a implementation before winehq did but the developer lost interest. We also have IMHO some stupid/lax rules in the ReactOS project that allow for anonymous developers to contribute code. I doubt Alexandre will accept patches from anyone using a pseudonym so I wont touch that code either unless Winehq has a better implementation and then I will blow away the anonymous ReactOS developers work.
I cant change the situation and I dont see it getting much better until the ReactOS project grows a little more and our developers learn to be a little more flexable. If Winehq is going to provide PE binarys of the dlls/programs we share, then we could just package our releases with that except for the fact sometimes our developers dont like to wait on Alexandre to commit stuff to the tree. Alexandre sets the rules and we try to play by the rules even if that means that some work gets duplicated. Sometime our developers dont want to wait on a submit->modify->comit/reject->merge->submit loop of Winehq so they put code in to ReactOS cvs first. Does it mean sometimes work gets duplicated? Sometimes yes. Its going to happen. Rather by mistake, or design some effort will be wasted.
IMHO the system we have in place is still better than what has happend in the past with projects using WINE code. Odin, Transgaming and even CodeWeavers (until recently) have maintained there own source base and then merged at set times. This lead to patches getting dropped, not being released due to it being under a incompatible license or just out right duplication of work.
Thanks Steven
__________________________________ Do you Yahoo!? Yahoo! Mail - More reliable, more storage, less spam http://mail.yahoo.com
duplicated. Sometime our developers dont want to wait on a submit->modify->comit/reject->merge->submit loop of Winehq so they put code in to ReactOS cvs first. Does it mean sometimes work gets duplicated? Sometimes yes. Its going to happen. Rather by mistake, or design some effort will be wasted.
This submit->modify->commit/reject loop has been proven a very good method of ensuring that the changes are of high quality. Dozens of projects other than wine operate like this, most visibly the linux kernel. I think its silly to put in changes because people don't want to wait. I'd imagine it is more error prone and given that Alexandre turns most patches around in days it seems pointless to try to circumvent this process.
Chris
On Mon, Mar 15, 2004 at 05:22:37PM -0500, Chris Morgan wrote:
duplicated. Sometime our developers dont want to wait on a submit->modify->comit/reject->merge->submit loop of Winehq so they put code in to ReactOS cvs first. Does it mean sometimes work gets duplicated? Sometimes yes. Its going to happen. Rather by mistake, or design some effort will be wasted.
This submit->modify->commit/reject loop has been proven a very good method of ensuring that the changes are of high quality. Dozens of projects other than wine operate like this, most visibly the linux kernel. I think its silly to put in changes because people don't want to wait. I'd imagine it is more error prone and given that Alexandre turns most patches around in days it seems pointless to try to circumvent this process.
Chris
I mostly agree. However, human nature being what it is and some people less patient than others...
If they want to try out some code paths on their own and commit it later to Wine, it's pretty much up to them. At least it gets tested a bit before Alexandre sees it.
I am very happy to see this level of cooperation between Wine and Reactos at all. Remember, the linux kernel gets forked all the time, patches are tried out and the good ones percolate up to Linus' tree.
On Wed, 17 Mar 2004 00:15:32 +0100, Jakob Eriksson wrote:
I am very happy to see this level of cooperation between Wine and Reactos at all. Remember, the linux kernel gets forked all the time, patches are tried out and the good ones percolate up to Linus' tree.
Perhaps Wine should start considering a kernel-like approach with some developers having their own trees where some experimental patches are tried out first then percolate up to Alexandres tree?
Another thing I'd really like to see is a move to GNU arch version control - it makes distributed development and branching a *lot* easier. I talked to Alexandre a bit about this at WineConf, and he mentioned on IRC that when arch is supported by emacs he'd think about it. Well, I now see on arch-user that there is such support, and the arch tools are maturing rapidly (see zoomarch etc).
It might be worth doing an experiment on using arch for Wine development.
Maybe if I get some time this holiday I'll try reviving my program to parse CVS commit messages back into filesystem operations and begin keeping an arch archive in sync with CVS so people can try it out. The last time I tried it I found turning commit messages into FS ops reliably was a pain in the ass, but I'm better at shell scripting these days.
I already parse commit messages in realtime for CIA (our irc commits bot) so I could easily extend this and put the results on navi.
What do people think?
thanks -mike
On March 17, 2004 8:44 am, Mike Hearn wrote:
Another thing I'd really like to see is a move to GNU arch version control
arch sure sounds interesting (except for the file naming conventions :)), but before we can consider switching we *must* have infrastructure available that's comparable to the CVS one. And here I mean: - cvsweb: for web browsing - cvsup: for fast synch - patch: for the winehq-cvs messages
Given that repositories are just files on FTP servers, maybe cvsup is not needed, but the patch facility we have is a must.
When all that is in place, we may consider looking into it, to see if the switch is worth the pain. Please remember that virtually everybody knows CVS, whereas almost no one knows arch, so for new (and existing developers) it's a big pain to switch. So we must have some pretty important reasons to go down this path, and "arch is a cool concept" does not qualify :)
On Wed, 2004-03-17 at 14:31, Dimitrie O. Paun wrote:
arch sure sounds interesting (except for the file naming conventions :)),
Yeah, they bug me too, but I don't think it's a big issue really.
but before we can consider switching we *must* have infrastructure available that's comparable to the CVS one. And here I mean:
- cvsweb: for web browsing
ArchZoom: http://migo.sixbit.org/software/archzoom/
ViewArch: http://arch.bluegate.org/cgi-bin/viewarch.cgi
From playing around it seems like ViewArch is closer to what we have
now...
- cvsup: for fast synch
Arch already has this built in, effectively. Arch works in a fundamentally different way to CVS - it's based on applying changesets in order rather than keeping track of HEAD and working backwards.
ie running "tla get wine" or whatever actually downloads the first checkin then all the patches and applies them in turn. Obviously that's too slow for most projects so you can stow cached revisions (ie tree snapshots) along the way so it only downloads the last revision then works from there. That only occurs on initial checkout of course.
From there "tla update" grabs each patch and applies it in turn.
- patch: for the winehq-cvs messages
Arch works with changesets natively, so you can run the relevant command with the patch ID to get this sort of output at any time.
When all that is in place, we may consider looking into it, to see if the switch is worth the pain. Please remember that virtually everybody knows CVS, whereas almost no one knows arch, so for new (and existing developers) it's a big pain to switch. So we must have some pretty important reasons to go down this path, and "arch is a cool concept" does not qualify :)
I think a compelling argument can be made for that. While everyone knows CVS the subset of commands we all use is tiny, mostly because only Alexandre commits. In fact I'd guess 99% of CVS usage on wine is:
* cvs update * cvs diff * cvs log/status
The equivalents in arch are:
* tla update OR tla replay (difference explained below) * tla file-diffs
There is no equivalent for file-based log/status AFAIK as arch doesn't track files individually like CVS does. The upside is that arch understands things like file renames/moves/symlinks.
OK, so why should we use arch? ==============================
Wine is a project that operates similar to the Linux kernel. There is a benign dictator, who controls CVS. We all grab CVS, hack in our own branches, separate the changes out into a patch and email it to wine-patches. Normally, if we got it right, Alexandre will check it in forming a logical changeset, and we then all run cvs update which downloads everyones changes.
This works OK but has a number of disadvantages:
* No branches. Some Wine work would be best done in parallel to the main tree. For instance, the filesystem work, the WM rewrite etc. Wines current modus operandi makes this very hard, as effectively CVS HEAD must be at least dogfoodable at all times. This also makes it hard to do R&D projects like the shared memory wineserver while keeping the results of that R&D usable.
* Hard to work on locally Not every patch we write gets checked in, this is the reality of life working on Wine. Sometimes because those patches are incomplete or wrong, sometimes because they get forgotten or missed, sometimes because Alexandre doesn't agree that the code belongs in the main Wine tree (things like the system tray patch, delayed debug tracing patch etc spring to mind).
Over time, a particular checkout of wine will accumulate debugging cruft, random unchecked in patches and so on. I already have one tree I've practically abandoned for new development because the differential got so large (11,000+ lines). It gets hard to separate out individual changes into atomic patches, especially when patches depend on each other.
Yes you could say I should never have allowed the diff to get so large, and believe me I wish it hadn't happened, but in practice people still use and apply patches like systray/debug tracing and expect me (!) to maintain them, so I need to keep them around in some form. There are also patches in there that bounced pending extra work that I never got around to and so on.
Nowadays I simply use separate checkouts of CVS to try and manage it all.
* CVS is not changeset oriented. It's really hard to easily do regression checks because the closest CVS has to this is date based rewinds. We try and slap changesets on top using patch.py, which works well, but CVS is not naturally inclined towards it. Arch lets you say "rewind to this changeset" and it'll just do it. Binary searches become a lot simpler.
* Hard to get into "The Zone"
Sometimes, some people or teams of people will have a mad coding session and produce a ton of patches. The Direct3D work by Jason, Raphael and Christian last year is one good example. My WineCfg work was another. Unfortunately our current model makes this a total pain in the ass because the patches are against CVS not your previous work. I ended up writing some scripts to help with this, by having two trees which I applied patches to in sequence then generated a diff against. It was annoying. This is especially true if AJ bottlenecks - for instance during some of the D3D work he was on holiday.
Why does arch work better? ==========================
Arch is far from perfect, in particular it's rather quirky and has a ridiculously complex command line interface. However, it has one feature that is make or break : distributed branching/merging.
In arch you can have a tree in an archive somewhere up on the net, and others can make a branch of it in their own archive and start checking in changes. They can remerge periodically and arch will just deal with problems like multiple remerges (in both directions). The owner of the original tree can merge the branch into their own when the time is right, or cherrypick changesets and just apply them.
In other words, I could branch WineHQ, and make some changes, then you Dimi could branch *my* tree and make some changes yourself and so on.
So how might Wine development look in a post-arch world? ========================================================
Here's one vision. See what you think.
Alexandre of course remains the ultimate maintainer and dictator of Wine. His tree is the canonical one which we all work from, and he does releases of his tree a la Linus.
However, let's say I engage on a particular project (make WinFoo work). Maybe I'm doing it for a customer, maybe I just want to make people in #winehq happy. I can grab WineHQ, branch it, and start committing. Along the way, I can submit each changeset back to wine-patches with a very simple script: arch will generate a whole-tree changeset with one command. When I next commit of course the diff will be reset to zero so I don't end up with bits of other patches interfering.
Alternatively, if there are a lot of patches which depend on each other, Alexandre can pull the tree directly and use archs built in merging operations to synchronise the two. I can keep on working while this is going on by the way - AJ can merge with my tree as many times as he likes, and vice-versa.
Let's say only 90% of the patches I write to make this app work get checked into WineHQ. Users who only care about this app are still happy as they can just "tla get mike@navi.cx--wine--winfoo" and grab a version of Wine that works for their app. The community is happy because the bulk of the patches got back to the main tree anyway.
Let's say Jason, Raphael and Christian have another D3d codefest. The best way to work on this is for one of them to branch WineHQ and start work. The others branch this subtree *again* and begin work on their own trees. The temporary D3D "maintainer" merges with the other guys work, and so nobody bottlenecks on AJ or has to stop work for a few days while the patch queue clears so they can get clean diffs easily.
The end result of that work can be then trivially merged back into WineHQ. Alexandre can review the entire patch at once to get the zeitgeist of it, while still seeing the progression of the code if he wishes. Meanwhile the huge code churn doesn't impact others working on other parts of the codebase.
It'd also make it practical for Wine to split into subprojects for really huge pieces of work. For instance, currently MikeM is hacking on MSI alone. If he had the ability to setup a separate project for it, and invite others to begin work with him, it might be easier to get people involved. Once the work has matured the project can be terminated and we go back to the central peer-reviewed model.
So, what do people think? There are tools to sync CVS and arch, I can set one up over the holidays (starting for me on saturday) so we can get a flavour of it, if there is interest.
thanks -mike
Hi Mike,
IIRC for D3D, we had been discussing about setting a cvs repository at that time. Then we dropped this idea, due to merging complication.
Bye, Christian
BTW, you have forgotten to mention Lionel :-)
I think a compelling argument can be made for that. While everyone knows CVS the subset of commands we all use is tiny, mostly because only Alexandre commits. In fact I'd guess 99% of CVS usage on wine is:
- cvs update
- cvs diff
- cvs log/status
The equivalents in arch are:
- tla update OR tla replay (difference explained below)
- tla file-diffs
There is no equivalent for file-based log/status AFAIK as arch doesn't track files individually like CVS does. The upside is that arch understands things like file renames/moves/symlinks.
OK, so why should we use arch?
Wine is a project that operates similar to the Linux kernel. There is a benign dictator, who controls CVS. We all grab CVS, hack in our own branches, separate the changes out into a patch and email it to wine-patches. Normally, if we got it right, Alexandre will check it in forming a logical changeset, and we then all run cvs update which downloads everyones changes.
This works OK but has a number of disadvantages:
- No branches.
Some Wine work would be best done in parallel to the main tree. For instance, the filesystem work, the WM rewrite etc. Wines current modus operandi makes this very hard, as effectively CVS HEAD must be at least dogfoodable at all times. This also makes it hard to do R&D projects like the shared memory wineserver while keeping the results of that R&D usable.
- Hard to work on locally
Not every patch we write gets checked in, this is the reality of life working on Wine. Sometimes because those patches are incomplete or wrong, sometimes because they get forgotten or missed, sometimes because Alexandre doesn't agree that the code belongs in the main Wine tree (things like the system tray patch, delayed debug tracing patch etc spring to mind).
Over time, a particular checkout of wine will accumulate debugging cruft, random unchecked in patches and so on. I already have one tree I've practically abandoned for new development because the differential got so large (11,000+ lines). It gets hard to separate out individual changes into atomic patches, especially when patches depend on each other.
Yes you could say I should never have allowed the diff to get so large, and believe me I wish it hadn't happened, but in practice people still use and apply patches like systray/debug tracing and expect me (!) to maintain them, so I need to keep them around in some form. There are also patches in there that bounced pending extra work that I never got around to and so on.
Nowadays I simply use separate checkouts of CVS to try and manage it all.
- CVS is not changeset oriented.
It's really hard to easily do regression checks because the closest CVS has to this is date based rewinds. We try and slap changesets on top using patch.py, which works well, but CVS is not naturally inclined towards it. Arch lets you say "rewind to this changeset" and it'll just do it. Binary searches become a lot simpler.
- Hard to get into "The Zone"
Sometimes, some people or teams of people will have a mad coding session and produce a ton of patches. The Direct3D work by Jason, Raphael and Christian last year is one good example. My WineCfg work was another. Unfortunately our current model makes this a total pain in the ass because the patches are against CVS not your previous work. I ended up writing some scripts to help with this, by having two trees which I applied patches to in sequence then generated a diff against. It was annoying. This is especially true if AJ bottlenecks - for instance during some of the D3D work he was on holiday.
Why does arch work better?
Arch is far from perfect, in particular it's rather quirky and has a ridiculously complex command line interface. However, it has one feature that is make or break : distributed branching/merging.
In arch you can have a tree in an archive somewhere up on the net, and others can make a branch of it in their own archive and start checking in changes. They can remerge periodically and arch will just deal with problems like multiple remerges (in both directions). The owner of the original tree can merge the branch into their own when the time is right, or cherrypick changesets and just apply them.
In other words, I could branch WineHQ, and make some changes, then you Dimi could branch *my* tree and make some changes yourself and so on.
So how might Wine development look in a post-arch world?
Here's one vision. See what you think.
Alexandre of course remains the ultimate maintainer and dictator of Wine. His tree is the canonical one which we all work from, and he does releases of his tree a la Linus.
However, let's say I engage on a particular project (make WinFoo work). Maybe I'm doing it for a customer, maybe I just want to make people in #winehq happy. I can grab WineHQ, branch it, and start committing. Along the way, I can submit each changeset back to wine-patches with a very simple script: arch will generate a whole-tree changeset with one command. When I next commit of course the diff will be reset to zero so I don't end up with bits of other patches interfering.
Alternatively, if there are a lot of patches which depend on each other, Alexandre can pull the tree directly and use archs built in merging operations to synchronise the two. I can keep on working while this is going on by the way - AJ can merge with my tree as many times as he likes, and vice-versa.
Let's say only 90% of the patches I write to make this app work get checked into WineHQ. Users who only care about this app are still happy as they can just "tla get mike@navi.cx--wine--winfoo" and grab a version of Wine that works for their app. The community is happy because the bulk of the patches got back to the main tree anyway.
Let's say Jason, Raphael and Christian have another D3d codefest. The best way to work on this is for one of them to branch WineHQ and start work. The others branch this subtree *again* and begin work on their own trees. The temporary D3D "maintainer" merges with the other guys work, and so nobody bottlenecks on AJ or has to stop work for a few days while the patch queue clears so they can get clean diffs easily.
The end result of that work can be then trivially merged back into WineHQ. Alexandre can review the entire patch at once to get the zeitgeist of it, while still seeing the progression of the code if he wishes. Meanwhile the huge code churn doesn't impact others working on other parts of the codebase.
It'd also make it practical for Wine to split into subprojects for really huge pieces of work. For instance, currently MikeM is hacking on MSI alone. If he had the ability to setup a separate project for it, and invite others to begin work with him, it might be easier to get people involved. Once the work has matured the project can be terminated and we go back to the central peer-reviewed model.
So, what do people think? There are tools to sync CVS and arch, I can set one up over the holidays (starting for me on saturday) so we can get a flavour of it, if there is interest.
thanks -mike
On Sun, 2004-03-28 at 22:34, Christian Costa wrote:
IIRC for D3D, we had been discussing about setting a cvs repository at that time. Then we dropped this idea, due to merging complication.
Well, this is the sort of thing that I hope arch will help with :)
BTW, you have forgotten to mention Lionel :-)
OK, it's official, I suck. Sorry Lionel!
On Wednesday 17 March 2004 07:44 am, Mike Hearn wrote:
Another thing I'd really like to see is a move to GNU arch version control
What do people think?
I'm using it at my new job and it's pretty dope imho. There are a few downsides, some already have been mentioned (those--horrible--names, for example). Others I have noticed:
o Too many VC files & VC Files mixed in too liberally with your real source ("inventory" helps ameliorate this, but still...)
o Not the best win32 support AFAIK
o working in /x/y/z amazingly requires write permission at /x/y! stupid.
o horrible, confusing error messages
o no fancy integration with your favorite GUI yet
Despite the above and a few other nits, I really like it. Even those--damn--names start to get comfortable once your ring finger builds up the requisite strength & dexterity :)
--- "Gregory M. Turner" gmturner007@ameritech.net wrote:
o Not the best win32 support AFAIK
We already turn way to many Win32 developers off to WINE as it is.
__________________________________ Do you Yahoo!? Yahoo! Mail - More reliable, more storage, less spam http://mail.yahoo.com
On Wed, 17 Mar 2004 13:44:50 +0000 Mike Hearn mike@navi.cx wrote:
Another thing I'd really like to see is a move to GNU arch version control
I'm using Arch on all my own projects and I think its great. Still needs a little polish, but its improving really quickly.
There is also a concerted effort going on to fix its current windows- unfriendliness (issues with handling case-insensitive filesystems and very long path names).
Maybe if I get some time this holiday I'll try reviving my program to parse CVS commit messages back into filesystem operations and begin keeping an arch archive in sync with CVS so people can try it out.
Have a look at cscvs:
http://wiki.gnuarch.org/moin.cgi/cscvs
"cscvs is a tool which implements an abstraction layer over CVS constraining it to operations which have atomic changeset semantics. If you need to maintain a project on both CVS and Arch, you should really have a look at it."
What do people think?
I think Arch will work really well for the very highly distributed nature of Wine development.
Erik
-
Alexandre Julliard -
Chris Morgan -
Christian Costa -
Dimitrie O. Paun -
Dimitrie O. Paun -
Erik de Castro Lopo -
Ge van Geldorp -
Gregory M. Turner -
Jakob Eriksson -
Mike Hearn -
Shachar Shemesh -
Steven Edwards -
Tom