Exercise: what are the downsides of the current generation of DVCS ?
(Assume you may be something other than a coder that carries all files in a laptop.)
(Assume you may be something other than a coder that carries all files in a laptop.)
You can try to cronjob the updates, staggered around 4am. Or you can realize that the majority of people are only modifying a subset of these assets, and roll your own link-based asset manager for large binaries.
[1] http://news.ycombinator.com/item?id=1201559, http://news.ycombinator.com/item?id=1219082, http://news.ycombinator.com/item?id=1222905, http://news.ycombinator.com/item?id=1242374
You handle versioning either through filesystem snapshots, or by just using different paths for each version.
Of course not, it's not their problem. What annoys me is that the "You must use DVCS" memo is being sent around uncritically, and anyone who does not fit the use case is left out.
I think that people who deal with images/spreadsheets/data would also benefit from a good VCS tool. If the coders, having scratched their itch, did not declare the problem solved and move on ...
P.S. thanks for the polite answer. So, there is either no problem or no solution ... I think we're done here.
No version control system, centralized or distributed, actually handles blobs better than just treating them as artifacts and using rsync.
The only way to actually solve the problem is to make the data not be blobs anymore, where the diff/merge/serialization code all understands at least the structural container format and can render it usefully. There's never going to be a general purpose tool that does that outside of a live-in smalltalk image (or similar).
The best you're going to get is tools vertically-integrated with the application, and all the ones I've seen to date (MS Office, Adobe Version Cue, etc.) all do a terrible job of even doing diffs/RCS, much less actually implementing a real VCS.
It's interesting that the names are "Distributed Version Control Systems", or "Revision Control", but the ghost of the word "source" (meaning code text, in 1972's SCCS) is still read into it.
Surprisingly, when DVCS are shouted as the bees' knees for everybody, people who have images, documents and data may think they were included. Apparently not, those benighted heathens should use rsync or whatever manually, and not soil the "source control" systems with their binaries. Or go find not-included plug-ins, if they can.
(Those people are apparently too dumb to understand that a binary "artifact" produced with an image editor, spreadsheet, or data analysis tool is fundamentally different from a blessed code file written with a text editor, and thus is not entitled to be under real version control, or have a DCVS tool automatically do something smart about it.)
The Perforce guys must be laughing their asses off.
I don't think you'll find a satisfactory tool that has as its primary use the management of texts and deltas of texts. You'd probably need to use a combination of tools which has its own set of frustrations.
BAM solves this problem with a hybrid approach. BAM adds the concept of one or more BAM servers. Each BAM server contain all BAM data, but clones of the server (work spaces) contain only that data that the user requests. Typically this is the most recent version of each binary but in some cases it may even be less than that.
BAM has been successfully deployed in the game development space with great success. Game developers continue to enjoy the benefits of distributed work flow without the penalty of carrying all versions in every workspace.
By default all files are set read only. This was a big downside when you had no internet connection.
Of course, if you don't mark it writable (and just use :w! in Vim, for instance), then a 'p4 sync' may eat your work if anyone's changed the file.
I don't see it happening anytime soon as long as it justified using "its _source_ control". There are programming activities that require large binary files to be versioned along with source and this is a clearly a limitation of DVCSes IMO.
Apart from that I am quite happy moving to bzr from svn. Life is much easier now.
The hardware part seems limited: "the Alpha group ... hardware description language files into Vesta's source code control", so not schematics or layout binaries as 'source'.
That site seems to be resting since 2006, but there is some activity at http://sourceforge.net/projects/vesta/ (releases in 2009, mailing lists with 2010 messages).
1) Large binary or data files -- For this, there are various solutions of varying hackiness.
2) Your project has grown into several sub-projects -- The best solution here is to clone the repository to new names and then refactor and trim the respective project trees with a lot of deleting. You'll thank yourself later for improving your architecture and there will no longer be a partial check-out problem.
The real issue for both of these, is handling unversioned or independently versioned bits with respect to all the other bits. You might want some unversioned binary blobs, but you might also want some versioned giant csv files without having to download all the old versions all the time. Source code has one versioning strategy, data files another, photoshop files yet another. No version control system today really lets you pick which versioning strategy to use for which files. And none of the existing "sub-module" type extensions are really great either.
4) The project has grown into several sub-projects - but you don't control that repository.
"shallow repository A shallow repository has an incomplete history some of whose commits have parents cauterized away (in other words, git is told to pretend that these commits do not have the parents, even though they are recorded in the commit object). This is sometimes useful when you are interested only in the recent history of a project even though the real history recorded in the upstream is much larger. A shallow repository is created by giving the —depth option to git-clone(1), and its history can be later deepened with git-fetch(1)."
There are still issues; you can't commit for instance, but you can update to HEAD to update your patch, with a depth of 1 you only get the most recent changes.
Two of the features that made it difficult to 'sell' Hg for the main SCM of FreeBSD were the lack of Partial checkouts and Partial history
The problem with that, of course, is that merging only makes sense if you are merging branches that occur at the same tree-level in a project. This is why subversion merge tracking is so buggy and half-baked... because any given directory could be a project tree, a subtree, a branch, or a tag, and you could merge any of them. Sure if stick to certain conventions it works pretty well, but technically the whole implementation is a minefield, which is why svn will never be as robust as other systems that don't make this mistake.
Even though git's submodules and subtrees leave a lot to be desired, and have significant room for improvement, they will never be as convenient for partial checkouts, because the requirements for svn-style partial checkouts require crippling the entire system.
[1] http://doc.bazaar.canonical.com/latest/en/user-guide/filtere...
- Hard to explain to even fairly technical designers/copywriters.
- With all that easy branching, I sometimes just have a hard time getting a decent version of the codebase together from everyone.
http://lukepalmer.wordpress.com/2008/11/12/sketch-of-udon-ve...
git filter-branch --subdirectory-filter foodir -- --allI did it in the project I'm working on now! It originally had one main repository, and another for an extension that was used as a git submodule in the main one. Active development proceeded in both, with shitloads of commits in the main one just to update the reference to the submodule.
I decided this was retarded, so I took a clone of the extension repository, used filter-branch to rewrite it's entire history so that all the paths were always prefixed with "vendor/extensions/project_name/", and pushed it as an unrelated branch into the main repository.
Then in the main repository I made a new branch, removed the old submodule junk there, did a nice clean merge that melded all the commits from the extension branch going back in time, and made that the new master branch.
I suspect Linus likes the approach not because it has no politics, but because it encourages the politics that match the way he'd like to manage the Linux kernel development, with this style of hierarchical, cascading commit approval, which is pretty hard to set up in CVS (though Mozilla's sort of grafted it on via their Bugzilla, which keeps track of cascading approvals of patches based on who owns which areas and sub-areas). Not that that's necessarily a bad thing, it's just different (and for a project as large as Linux, probably necessary).
Suppose I sit down for a collaborative session with someone. Over the course of a few hours, we might generate 10-100 commits between the two of us, and several branches, all to implement a single feature. I.e., I commit, say "hey, pull from me, you had an off by one a few minutes ago."
At the end of the session, we only want to generate a single commit to the public repositories.
Mercurial queues are a tolerable way to handle this, but they aren't great.
http://stackoverflow.com/questions/598672/git-how-to-squash-... and
http://stackoverflow.com/questions/435646/how-do-i-combine-t...
[1] http://doc.bazaar.canonical.com/plugins/en/rebase-plugin.htm...