21–30 of 30 posts
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. :(
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. :(
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. :)
Earlier quoted context omitted.
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?
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.
I don't get why any of this can't be layered on top of an existing DVCS.
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.)
"(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.
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
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.
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. :(
http://www.kernel.org/pub/software/scm/git/docs/git-read-tre...
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 awf…