New DVCS with integrated bug tracking and scrum metrics | Hacker News Reader

New DVCS with integrated bug tracking and scrum metrics

veracity-scm.com

28 pointsjosephcooney29 comments

I don't get why any of this can't be layered on top of an existing DVCS.

Agreed. That's exactly what we set out to do with Git. Shameless plug: http://gitpilot.com/

Yeah. That's conspicuously absent from the "questions" page. e.g. "Why a new DVCS"? or "What problem does veracity solve?"

They are a VCS company, why would they out source their core competency? Second that kind of seems to be their MO, knock off an existing system, only do it better(their primary product is a visual source safe done right.) From what I have read, it seems like it will be away for Corporations to move to this fancy new DVCS thing while still maintaining a modicum of control and centralization(it supports file locks.)

I still can't quite wrap my head around what it means for a DVCS to have exclusive locks. It seems like either the locks aren't exclusive or the system isn't distributed.

Edit: this kind of covers it: http://veracity-scm.com/qa/questions/102/why-would-you-desig...

I guess upstream is somehow aware of all downstream repos and can communicate with them outside of push-type operations?

My guess(since there is a dearth of documentation at this point) is that it is token based. When you say a file requires locking it records that the file needs to be locked and that you currently own the lock. Then as you push, knowledge of the fact that this file needs a lock is spread.

The only other option I really see working is having a designated lock node, so you are centralized only when you need to do locking.

"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.

How does file locking work in a DVCS?

edit: I tried reading the code in sg.c and sg_vc_locks.c and I don't understand what the purpose is. Basically It just breaks someone else's push if you have a lock?

edit2: Why can't I clone the veracity repo? Odd that a version control system doesn't seem to be self hosted. Unless I'm overlooking something of course. Nevermind: http://public.veracity-scm.com/repos/veracity

If it used Git underneath I'd willing to try, otherwise it would be procrastination right now.

Hey guys. I'm the dev manager for Veracity. I thought I could answer a couple of questions.

On the problem it solves: stonemetal has it about right. Veracity wants to be a way for companies to take advantage of DVCS without giving up many things they need. The Apache license and file locks are a couple examples that exist today. We have plans for more. We're not trying to out-git git.

On documentation: yeah, it's awfully sparse right now. We're working on it. We didn't think the Q&A site would solve the problem, but we do hope it ameliorates it somewhat in the mean time. :)

How do you handle file locks? If A locks main.c and B pushes seven commits from his local repo with the oldest modifying main.c what is the end result?

This is from the SourceGear guys, Eric Sink's company. If you dont know what the do check out sourcegear, they make some great stuff for developers in the .Net stack.

This site is missing a LOT of info no? I'd like a little bit more info before I download a file... Must i download just to read docs? Are there even docs bundled?

Quite amazing that there isn't even a "Documentation" link on the site. I wonder if they think that having an embedded Q&A/Stackoverflow component to the site takes care of this.

Is it too much to ask for at least one dvcs to implement true sparse checkouts? It's the only reason I'm stuck with svn right now. :(

What's the use case for this?

Quicker checkouts, less data on drive?

The whole history in git can be (and usually is) than a working copy in SVN. Don't get me started on the speed.

The actual checking out goes faster with SVN, nevertheless, because it's so much less data (assuming a decent amount of history). I'm not stating a preference, just facts.

Downloading multi-gigabyte git repos just to work on a very small subset of it.

See the "--depth" argument to git-clone.

See the "--lazy" argument to darcs-get.

The "--depth" argument to git-clone, as of 1.7, produces a read-only repository, which rather defeats the point.

This works for me. What's read-only about the repositories that you get?

Or bzr lightweight checkouts?

Not that it's a DVCS, but I remember ClearCase had this brilliant "dynamic" mode which would hook into explorer and simulate a drive with the entire contents of a repo, but only download the files you need when you needed them. I haven't seen that anywhere else

http://www.kernel.org/pub/software/scm/git/docs/git-read-tre...

You're still downloading the whole history. That can be very painful on very large projects.

most of the grey git boxes on that comparison chart could be filled with a "github"

...or google code, bitbucket, or launchpad. I think you're missing the point: veracity has all of these features built in.

I'm not sure baking all of tyyese features in to the VCS is going to be a winner long term, but they've got some interesting ideas.

Reply on news.ycombinator.com