z-man wrote:
* SF now also offers Subversion, and if I read the notes right, the setup doesn't suffer from the single point of failure that brought down CVS.
* If we go with a self-hosted, distributed source management system, we need a distributed source management system :) CVS and SVN won't work too well. We need something like
Bazaar or the thing the Linux kernel is now managed with.
I've been using
darcs for the past few months. We should also look at GNU arch, I haven't yet because it seems so complicated.
* Instead of replacing SF's CVS service, we could build a reliable structure around it. In the work-from-home period of the late CodeCult, I had a crude bash script collection mirroring a MS SourceSafe system (which REALLY sucks, and which I didn't have 24 hour access to because I was on a dialup line) to a local CVS repository and worked with CVS instead. Something similar must exist already to mirror CVS repositories to something else or CVS.
On the darcs wiki there is a tutorial to keep CVS and darcs in sync. I almost set it up one day, but our repository is semi-huge, I probably should just do the latest version. We don't need to migrate our whole tree.
* I'd like a bug tracker and source manager that go hand in hand, i.e. that make it easy to link a fix entry in the bug manager with the corresponding source change. Both ways. So that the changelog of the source contains "Fixed bug #bla" and the bug log contains "fixed in revision 1.4.5 of tFoo.cpp". Without me having to dig out that info and paste it in.
* I'd like a bug tracker where we can give users a single link that lists all bugs that version 0.2.8.2 is affected by. That and the previous points are the only things I personally *really* miss in the SF trackers.
Trac is a great bug-tracker. Right now it only supports subversion, I know that a future version will allow any SCM system to plugin, but not yet. I believe several darcs evangelists submitted the patches.
z-man wrote:I know what that means, yes :) Easy installation for everyone.
Most of it is in C (well, it took a long time to install. I assume it was in C and was compiling...), and it requires a few dependencies. Still, it is much easier to install than darcs, which requires The Glorious Haskell Compiler. If you use a source based distro or want to compile it yourself -- it sucks to be you!
The nice thing is that logs are merged, too, so on merge, you don't get a meaningless "merged changes from Luke-Jr" message, but a "Merged changes from Luke-Jr, who sais he has fixed bug #24" style log message. So automating the merging is a snap, a small shell script that does
bzr merge <luke's branch>
bzr commit -m "merges from luke"
does the job if there are no conflicts. If luke does "bzr pull" often enough to keep his branch up to date, he's the one who has to deal with the conflicts. Our setup should enforce this.
Revisions in bzr are global. You don't get the tFoo.h revision 1.2 and tFoo.cpp revision 1.8 divergence you have in CVS. The whole repository has one revision number.
Concerns: Will the local "checkouts" contain all the information from the central repository and thus grow pretty big?
In stable branch
darcs pull <luke's branch>
or if you are in luke's branch
darcs push
Darcs will by default grab the whole repository when you do a checkout. Every branch is it's own repository, so means the checkout will be huge. Luckily, you can tag the repository using "darcs tag". Then you do "darcs get <repo> --partial" and it will only pull the changes since the last tag, or you can use --tag to get a specific tag.
Will it handle binary files well? What about the nasty end-of-line difference problem between Windows and *ix?
darcs handles binary files well. I am not sure about line ending handling.
z-man wrote:
I think bazaar handles the different repositories at different locations like CVS handles branches, the only difference is that they're stored in separate physical places. The changes to different repositories are tracked individually, and you can later just "merge" two repositories back into one (or into the main, central repository). The thing I really don't grok yet is how you manage an "official" central bazaar repository yet, it looks more like it is intended for more anarchic development styles. Which we may like, as it simplifies patch management if the patch submitter uses bazaar as well.
This is like darcs, and all distributed SCM systems.
You would have a central repository on some server. Everyone would push or pull their changes from this repo. Since we need to have concurrent development in several branches, we need to have several repositories.
http://scm.armagetronad.net/repos/unstable -> HEAD
http://scm.armagetronad.net/repos/0.2.8 -> (when a release is made, darcs tag on this repo)
...
<person with commit access>
$ darcs get
http://scm.armagetronad.net/repos/unstable --repo-name armagetronad-unstable -> grab HEAD. This isn't a checkout, it is a standalone repository.
$ cd armagetronad-unstable
$ darcs record -am "Added ramps"
$ darcs pull -> pull in changes and sort out conflicts
$ darcs push -> push your changes back to scm.armagetronad.net
$ darcs changes
Sun April 4 07:39:18 CET 2006 Me
* Added ramps
bzr automaticall ignores CVS management directories, you just have to add the .bzr directories to .cvsignore and both systems will stay each other out of the way.
One major shortcoming of bzr right now: it does not support tags, so keeping the central repository as CVS/SVN and only using bzr (or whatever else we decide to use, but bzr just seems to support everything we need for that purpose) for redundant mirrors seems the way to go.
darcs keeps everything in a toplevel _darcs directory. It doesn't scatter files around your repo. It also automatically ignores .cvs and CVS/ (see _darcs/prefs/boring for repo specific settings, or ~/.darcs/boring for default settings).
Other random stuff:
Moving files: darcs mv file newname
Removing files: rm filename, darcs record
Recording patches: darcs record. Lets say you went through and made a few bugfixes, and you also changed some variable names to be more logical. Instead of recording this at once (and losing information on what you did), you can say no to record some of the changes you did to the file. Darc isn't like other SCM systems in this aspect. Darcs will prompt you for what changes you would like to record.
Code: Select all
$ darcs record
hunk ./foo.txt 3
-change this!
+changed!
Shall I record this patch? (1/?) [ynWsfqadjkc], or ? for help: y
hunk ./foo.txt 7
+added more words
+
Shall I record this patch? (2/?) [ynWsfqadjkc], or ? for help: n
What is the patch name? Changed it
Do you want to add a long comment? [yn] n
Finished recording patch 'Changed it'
$ darcs changes --verbose
Tue Apr 4 17:31:29 CEST 2006 Daniel Harple
* Changed it
hunk ./foo.txt 3
-change this!
+changed!
Tue Apr 4 17:30:58 CEST 2006 Daniel Harple
* Initial record
addfile ./foo.txt
hunk ./foo.txt 1
+blah blah
+
+change this!
+
+blah
