[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gnu-arch-users] Wine considering using arch for developement
[Gnu-arch-users] Wine considering using arch for developement
Sat, 20 Mar 2004 02:53:33 -0500
This comes from 'http://www.kerneltraffic.org/wine/latest.html'
2. Investigating Arch for Revision Control 17 Mar (5 posts)
Archive Link: "Branching/version control [was Re: cards.dll]"
Topics: Project Management People: Mike Hearn, Dimitrie Paun,
This topic came up on IRC so I was quite happy when Mike Hearn
mentioned it on the wine-devel list as well. There has been a
bit of discussion about moving from CVS to another revision
control program. CVS has definitely served it's use over
the years, but moving to something else may provide enough
benefits to offset the change. Mike briefly summarized what
he was considering:
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
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
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?
The emacs tool that Alexandre prefers is pcl-cvs. It's a
front-end to CVS that allows many things to be performed as a
single keystroke. Dimi cautioned against switching to a system
people are less familiar with:
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 :)
This led Mike to put together a really nice list of things that
arch could for Wine and how development could be improved. Some
of the tools Dimi wanted replacements for already exist:
+ ArchZoom: http://migo.sixbit.org/software/archzoom/
+ ViewArch: http://arch.bluegate.org/cgi-bin/viewarch.cgi
(and concerning cvsup...) 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.
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.
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
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:
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,
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_at_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
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
Greg Turner uses it for other work and likes it:
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
+ Too many VC files & VC Files mixed in too liberally
with your real
source ("inventory" helps ameliorate this, but still...)
+ Not the best win32 support AFAIK + working in /x/y/z
amazingly requires write permission at /x/y! stupid. +
horrible, confusing error messages + 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 &
Erik de Castro Lopo also had good things to say about it.
James Blackwell Using I.T. to bring more 570-407-0488
Owner, Inframix business to your business http://inframix.com
GnuPG (ID 06357400) AAE4 8C76 58DA 5902 761D 247A 8A55 DA73 0635 7400
- [Gnu-arch-users] Wine considering using arch for developement,
James Blackwell <=