ericsink

Two 23 year olds. One has been programming for 10 years, the other one just 4 years.

Isn't it sort of obvious that the person with more experience is likely to have more skills?

I need to look at Datomic.

Zumero could also be described as having similar characteristics as Git. It's like a DVCS, except for stuff that looks like rows and columns instead of stuff that looks like directories and files.

I'm sure that any decentralized database violates ACID in some way, but Zumero is pretty darn ACIDic. All the local CRUD operations are ACID. And the sync to the server is ACID, or highly corrosive at minimum. But yes, the two operations are separate.

Developers used to be afraid of automatic merging and conflict resolution in version control tools. We evolved.

Many of those techniques also apply to merging and conflict resolution of database stuff. In fact, from a certain perspective, the screw cases are a bit easier.

http://zumero.com/docs/zumero_core.html#chapter_conflicts

At the present time, Zumero doesn't allow sync of a partial table. If we sync only part of a table down to a device, then SQLite doesn't have the ability to enforce a UNIQUE constraint.

SQLite does have excellent support for using multiple database files together (using ATTACH), so there is plenty of opportunity for setting things up to ensure that each device only syncs the data it needs.

I think Perforce should buy it.

IIRC, the real reason for this "power of 2" is for fast rehashing when the table grows. Calculate a 32 bit hash and store it all, but if your table currently has 1024 entries, only use 10 bits of it. Later, when your table grows to 2048 entries, you can just mask off 11 bits worth instead of recomputing every hash.

But, since the hash table is not going to grow in this particular case, any perf gain from using a power of 2 will probably be far less important.

Actually, I don't have a smart phone.

Until recently, I did. It got broken. When I went to replace it, I realized that my iPad has displaced my smart phone in almost every way.

So I bought a flip phone.

I charge the battery every week whether it needs it or not.

I've read over 80 novels on my iPad. Love it.

I haven't tried a Kindle. I don't doubt that it's a better device for just book reading. But my iPad suits me well.

Veracity has a database feature which might be what you are envisioning. (Disclosure: I am one of the developers of Veracity). But I would not describe it as document-oriented. It versions a collection of records with fields in the same way that regular version control manages a collection of directories and files, with support for history and changesets and push and pull.

Apologies to folks having difficulty. Book requests are still coming in, so the system is definitely operational. We'll be investigating the problems this morning. For now, my only guess is that it is related to the load, so I suggest you keep trying.

I just wanted to make sure none of those crooks in Congress got a free copy of my book, but I keep forgetting that other people live there too.

:-)

Seriously, sorry for the oversight. We'll fix this.

"knock off an existing system, only do it better"

"(their primary product is a visual source safe done right.)"

If I may quibble with this comparison, I would point out that we built Vault because SourceSafe is a deeply flawed product, whereas Git is not a deeply flawed product.

We built Veracity because we think DVCS is the future of our industry and we want to be a part of that. I don't think Git and Mercurial are the end of innovation in version control. I think the third generation of version control is just getting started.

We're not interested in trying to convince people from switching off Git or Mercurial onto Veracity. Why would we? Those people are already happy DVCS users.

But there are still millions of developers who have not yet made the switch from a centralized system to a DVCS. Git and Mercurial will get their share of those new users. We hope Veracity will be a viable option as well.

tghw's interpretation is closer to being correct.

A Veracity repo can have lots of DAGs (directed acyclic graphs).

A DAG in a repo can either be a "tree dag" or a "database dag".

Veracity's notion of a "database" is a model that is unique to Veracity, although its concepts are quite common. Records. Fields. Multiple record types. Simple constraints. Links between records. Simple queries. It's not SQL.

Nothing here implies that Veracity will help you, as a database developer on SQL Server or Oracle, manage the versioning of your schema and sprocs and so on. Those are interesting features, but they're distinct from (and a lot higher level than) the stuff I was describing.