Oh boy howdy! Patch-tag just got a bunch of new features.
For starters, we have repo browsing built on gitit. This may sound like an easy thing to do, and we sure thought it would be before actually doing it, but it turned out to be quite a chore. Gitit has some memory issues, and no user permissioning model whatsoever. But we duked the memory issues out with the haskell profiler, cobbled together user permissioning with some help from Benja Fallenstein, and now… it works!
Well, browsing works, diffs works, and there’s a sane repo history viewer. Still no wikis. But we’ll get wikis working soon, too, you’ll see.
You can now browse private repositories with gitit too.
Also pushed:
Better error handling for emails, so hopefully no more severely belated registration emails.
Repo view is better.
You can no longer delete a repo by accidentally clicking the delete link. It’s now a submit button, and even that has a nag screen that tries to convince you that repo deletion is a Bad Thing.
Did I forget anything?
Oh, we ended phase wild alpha: unlimited users may now sign up.
Finally, some bad news for our few 1 users… you know who you are, you all got emails. It’s official now. We are phasing out Darcs 1. Existing darcs 1 repos still work for now, but we turned off creation of new darcs 1 repos, and are encouraging… well, forcing, everyone to move to darcs 2. In a bit — don’t worry, there’s still time. On the plus side, darcs 2 is better than darcs 1 in almost every way, so you should actually send us flowers and candy for twisting yalls arms. In all seriousness, dropping Darcs 1 was a tough call but we are being realistic. We have very ambitious plans for patch-tag, and serving multiple versions of darcs just seemed like something that would bog us down that very few people actually used, and the ones that did use it arguably shouldn’t be. To enjoy a beautiful garden, one must sometimes prune.
So, anyway — behold the new and improved Patch-Tag.
Enjoy!
So . . . AWESOME!!!
Will you be submitting your memory fixes to gitit back upstream?
Actually, the memory issues mainly had to do with filestore. We did not fix anything.
It is because filestore-0.2 uses a diffing library which is very inefficient in terms of memory use. The next release of filestore should have this fix.That’s not quite accurate. We did make some changes to diffing in filestore, but these are included in the released version, filestore-0.2. At this point, there’s nothing in HEAD that hasn’t been released (except for the addition of the repository location to the cabal file). So, there shouldn’t be diffing-related memory issues with the current release of gitit.
Also, the change was not to use a different diffing library, but to switch from word-by-word to line-by-line diffing. We are still using Diff.
Thanks for the correction
I updated my reply.
Congratulations on the repository browsing!
What kind of difficulties do face supporting both darcs-2 and darcs-1 repositories?
Folks can get a lot of the advantages of darcs-2 repositories just by using the hashed format (this provides the same –lazy fetching, global cache, pristine cache robustness, improved handling of case insensitive file systems as darcs 2, with darcs-1 backward compatibility to boot, although without the improved conflict handling).
The darcs 2 format is less mature than darcs 1 and already has some bugs, so people may still be nervous about upgrading to it. We believe enough in it that we think all new repositories should be created in –darcs-2, and that anybody who has trouble with conflicts should upgrade.
Otherwise, I like leaving people the choice. But darcs-1 or darcs-2, everybody should be upgrading to the hashed format. It’s a no-brainer. (The darcs-2 format is implicitly a hashed format, so if you’re already using this, no action on your part is needed). That said, this takes a lot of explaining, which forcing everybody to upgrade to just upgrade to the darcs 2 format avoids
Also, it may be worthwhile to hang out in #darcs if you folks are on IRC any.
Just to flesh this out, I should point out that while the darcs-2 format is less mature than the darcs-1 format, the darcs 2 client fixes some bugs in its implementation of the darcs-1 format (problems with the pending patch, this weird issue where a file would be listed as both removed and added).
In other words, using a darcs-2 client is a good idea as a better darcs-1 at the very least!
Kowey, we aren’t having any specific problems using the darcs 1 client at the present time.
But one of our core values is “we make things easy” and part of making things easy is providing less choice in some things. The overwhelming majority of our users are on darcs-2, and the darcs-1 users didn’t seem too concerned about having to switch when we asked. We don’t want to have to have to answer questions about darcs 1 versus darcs 2 incompatibilities, or corner cases where darcs 1 has an advantage over darcs 2 — these will be fixed eventually, or so we hope. We don’t want our users to have to think about it, and we don’t want to think about it ourselves.
Moving forward, a lot of our strategy has to do with repository interconvertibility within different vcs and dvcs systems. I don’t want to say too much more about this, mainly because the plans are still in quite a fluid state. But what it comes down to is that supporting a repository format isn’t as simple as just supporting that format but providing tools to make it easy for that format to play with others.
If there is an outcry of demand for darcs-1 support, of course we will consider supporting it again.
Incidentally, we are working on an “e-z” solution for checking out a darcs 1 repository anywhere and having it appear in patch-tag as darcs 2 — the first link in our interconvertibility tool chain.
Excellent, thanks for the update! I agree with this move if you’re doing it to simplify matters.
Just a quick note, however: the darcs-2 client handles both darcs-1 and darcs-2 formats. No need for a separate client. (I’m sure this is old news to you, but I’m just being paranoid because you mentioned darcs 1 client
)
But yes, eliminating needless choice can be a good thing in the long run.
As for the issue of interconvertibility, we could certainly use a hand with http://bugs.darcs.net/issue1040
Cheers!