Slashdot Mirror
Git Adoption Soaring; Are There Good Migration Strategies?
Got To Get Me A Git writes "Distributed version control systems (DVCS) seem to be the next big thing for open source software development. Many projects have already adopted a DVCS and many others are in the process of migrating. There are a lot of major advantages to using a DVCS, but the task of migrating from one system to another appears to be a formidable challenge. The Perl Foundation's recent switch to Git took over a year to execute. The GNOME project is planning its own migration strategy right now after discovering that a significant majority of the project's developers favor Git. Perhaps some of the projects that are working on transitions from other mainstream version control systems can pool their resources and collaborate to make some standardized tools and migration best practices documentation. Does such a thing already exist? Are any folks out there in the Slashsphere working on migrating their own project or company to a DVCS? I'd appreciate some feedback from other readers about what works and what doesn't."
Why Git Is Better Than X.com/ YouTube - Tech Talk: Linus Torvalds on git (yeah, I'm a convert)
In my day job we are migrating to something totally new...clear case.
(shit).
http://michaelsmith.id.au
I always though bzr had the edge on git in terms of being a better DVCS. Is there a reason why the article seems to think that git is the default?
Wow, you're really asking for it...
In the UK and to a lesser extent here in Australia a "git" is akin to a moron.
And did you exchange a walk on part in the war for a lead role in a cage? - Pink Floyd.
Wouldn't it be funny if git were to become more popular than Linux? Linus would be remembered as the Finnish hacker who gave the world a decent source version control system. Oh and he also used it for his own kernel.
The problem is that the very upper management (that one that lives in another continent) has decided that we are migrating.... to Perforce.
When we tried to argue against it, that we actually prefer FOSS tools (support & integration being always better), the answer was: "oh don't worry, we bought a company-wide license"
I think the best SCM is that SCM which you known the best
JMule user, enjoy it : http://www.jmule.org
In what way?
I'll happily admit that I do prefer bzr for its UI, but I hardly think either is objectively "better", whatever that means.
HAND.
If the system you are migrating from manages trees, you should be fine. CVS migration is pretty easy and I understand that Perforce works quite well too (in both directions!). Most of the migration tools are listed in the GIT FAQ.
The places where people are likely to have trouble is migrating from tools that don't understand that there's more than one file. For example, RCS and SCCS both support branches, but in a completely different way to git (branches are per-file, they're not for the whole repository). This means that during conversion, something useful has to happen with them, but the right answer isn't clear to a program. If versions 1.1, 1.1.1.1, 1.1.1.2 and 1.2 of file "foo" exist, then versions 1.1.1.2 and 1.2 are on different branches and either may be the older revision. It's not clear if revision 1.43.1.3 of file "bar" is the same "branch" as "foo" 1.1.1.2 or not. Because RCS and SCCS deal with single files only, it's not possible to find an answer to these questions in the history files at all - if there is an answer, it's just a convention of the user. Essentially what's happening here is that the git import process requires information which isn't represented in the files you're converting from. For what it's worth, migrating from SCCS or RCS to CVS has a similar problem.
Personally, I've migrated from CVS to git for findutils (well, Jim Meyering did the actual migration; he migrated coreutils too). I haven't regretted migrating at all. It took me a long time of using git locally before I was comfortable migrating the master repo, though. As a git beginner the thing I found most worrying was that I found it hard to envisage the effect of the git command I was typing. The thing it took me a long time to figure out is that with a distributed version control system, it's safe to screw up your local copy, as long as you don't push the result.
I've been working with BitKeeper over the past 3 years. From what I understand Git and BitKeeper share exactly the same concept, all differences being minor ones (for example see http://versioncontrolblog.com/comparison/BitKeeper/Git/index.html). BitKeeper has been around for a while. Why is Git suddenly so popular? Is it so popular? What has changed?
I have migrated to svn many repos from older stuff, like SCCS and VSS. Migration strategies are important, and to decide about them you need to answer a few questions. First of all, ask yourself if git or DVCS is the best option for you, your project and your company. Just don't be led by hype. It may be that a centralized VCS like svn may be a better option. There are tools to make them perform as DVCS, like the plugins git-svn and bzr-svn. Second, ask yourself how much of the project history is needed, if any is needed at all. That may save you lots of time, disk, chaos and entropy. When migrating, it is very important to tidy up the repo. Purge unnecessary files, binaries, archives, branches, etc. I have seen people who use VCSs like a trashcan. Bad practices may sink the repository performance. After migrating, make sure users know how to use the repo and that understand the basic VCS concepts, either generic or specific for the VCS of choice. Try to remove practices and concepts from the older VCS. As you mentioned it, best practices are very important, and they are not easily found on literature. There is more I could say, but I guess by now it's ok.
I have watched Linus talk about git on google tech talks, and am inspired to use it.
Unfortunately I think I need a tool like TortoiseSVN for git because I am a git.
Fucker.
Shut up.
Right, that was always the weakness of git, and although it's improved I still have problems with its usability (or lack of it). For all the dumping Linus does on Subversion/Perforce and its ilk, they are easy to understand and it's basically always clear what you're doing. I haven't used git for a while, but last time I did it was like a box of sharp knives. Although hard to mess up the remote copy, messing up your local copy was much easier.
I'm trying to use git as much as possible --- I'm still pretty crappy at doing anything even slightly complicated with it, but even with minimal skills it's brilliant at keeping track of changes to local directories.
The only problem is that I'd really, really like a decent Eclipse git plugin. I'm used to using Subclipse for SVN, which is fantastic: I can point at a file or directory, say 'Synchronise with repository', and then get a graphical diff of every change and the ability to quickly and easily revert or commit changes on a per-change, per-file, per-group-of-file basis, etc. (And you can do this with any revision, which makes backing out one specific change very easy.) Doing the same with git's command line tools seems terribly clunky by comparison, especially when I'm struggling to remember the syntax, and the fundamentally unfamiliar workflow.
I do use the Eclipse git plugin at git.or.cz, but it's still very crude. The file decoration is invaluable, which lets me see at a glance which files are new/changed/pristine in the Eclipse project view, but actually trying to *do* anything with it is deeply unpleasant --- no synchronise view, no graphical diff, and some weird behaviour like if you point at a file, say 'commit this', you get a dialogue prompting you to commit *all* files. Which is not what I want. And there's lots of UI clunkiness all round, due to simple immaturity.
I've had some luck with giggle, but the UI is pretty bad, and some changes (I forget what; new files, perhaps) don't show up in it, which is a bit awkward. I've had a play with some other GUI frontends but they're all pretty nasty by comparison with Subclipse. Still, the git plugin is getting better with time --- I'm just hoping that Synchronise shows up soon...
It's not surprising that developers increasingly favour distributed version control. It's a much more flexible way to work - and if you need to continue working in a centralized way, you can still do that.
If you're migrating to Git, there are a few things you need to account for. Do you want to migrate the history, or make a clean break using the current head of the tree ? Migrating the history is usually hard if it is in a commercial tool, since commercial companies quite obviously do not design their tools to make it easier for you to abandon them (some provide export tools). If you choose not to migrate the history, you have the issue of having to keep the old revision control system around to debug/fix/review older releases.
You need to be clear about your decision. Import some example code into Git (perhaps from your existing repository), put it on a server and ask your developers to play with it to make sure they're happy with the feel and that they're confident they can work with it. Make sure you practice doing things like merging conflicts and merging older maintenance branches. If you do this right, most of your developers should be fairly enthusiastic about the switch when it comes. Make sure you account for Windows users - Git isn't so hot over on Windows and I don't think there is an official stable Windows release yet.
Other than this, there's really very little to it.
I haven't tried git, but I think that the pure fact that is developed in raw C and uses SHA-1 keys for revisions makes it a pain in the back.
Bazaar is way more convenient on this. Written in python, easily extensible, and uses easier numeric revisions, like SVN.
I used to use cvs, subversion and perforce. After switching to git, it feels a lot more powerful, at the cost of more things that can go wrong.
My workflow with subversion was:
- regular update: update, check/fix conflicts, continue work
- commit: update, pick files I want to commit with TortoiseSVN, verify the changes in the diff view, write log message, commit, continue work
On GIT:
- regular update: stash my changes, change to master branch, pull, check for errors or dirty files (mostly endian problems), switch to work branch, rebase from master, check for errors or dirty files, unstash my changes, check for errors or dirty files, continue work
- commit: update, stage the files I want to commit, commit them, verify the changes, push
At several stages some obscure thing could go wrong that I needed to look up in the manual or on the internet, or needed to ask someone who used it for longer. That doesn't mean I think GIT is bad, I just feel it takes more time to be fully productive with compared to older systems. And I miss a few minor things from svn, like keyword expansion or properties.
I've just gotten fluent with SVN versioning after using it for a few years now. I understand that part of what bothers me about it is what bothers Linus Torwalds aswell and had him write Git and I can follow his reasoning in his famous Google speech on Git *and* I understand the hype that ensues around Git and welcome it. That said, until Git has a neat set of stable mature GUI tools to use with it, I'm sticking with Subversion, TortoiseSVN and/or Subclipse. A mature working toolkit that I know how to handle and that works more or less flawlessly.
Even a toolset like that would've costed thousands ten years ago. That goes to show how far we have come in some areas of the software field.
We suffer more in our imagination than in reality. - Seneca
I'm working on the OpenJDK source tree through Mercurial. I couldn't be more satisfied. The tools are well structured, very easy to use, stable, fast and well documented. I don't miss any feature. Could anybody, who tried both and prefers Git, list some advantages of it over Mercurial? To me it just seems like a Git done right without the hype and too complex UI.
I am using Darcs and it seems to do the job. Is strange that it isn't even mentioned cause it has been around since quite some time and is pretty mature. The only problem I am having with Darcs is huge resource consumption (a copy of the repository is on a VPS with 256mb RAM, no swap) but you can move a repository by just copying it somewhere else (even across systems) without problems. What are the advantages of using Git/Mercurial/Bazaar? I think I need to mention that I am developing on OSX (but a copy of the repository is on a Linux system).
You're quite right. It seems to me that Git isn't intended to provide access to the latest versions of individual files. Git, like all DVCS's I know of, is essentially a version-control plugin for your filesystem. The filesystem itself provides the current version you're working with, and so it's only a matter of providing an http server over the directory or something like that. Which is exactly what GitWeb and Trac-Git provide, only they're better.
I'm sure git vs. hg will be the next $EDITOR war, so I'm wary of asking this, but: has any used both git and hg, and which did you (personally) prefer, and why?
Anyone else read that as "Girl Adoption Soaring; Are There Good Migration Strategies?"?
*goes hunting for coffee*
Mr. Period: Nine is the one that's right by ten!
Nine: One day I will kill him. Then, I will be Ten.
Use cvs2svn to convert your existing CVS repositories.
The tools that come with git for converting CVS to git do not work. You will see other posts about how git is different, such as how it manages commits versus files. CVS manages files, and doesn't track them well.
It has no ideas of when a branch ends, and even when they start is a bit iffy. Add to that the fact that CVS lets you pick and choose random files to be on a branch, then you can really start to get into a strange state.
For our CVS repository (goes back to 2001, we had 100's of branches, maybe 1000 tags), the git cvsimport tool placed code from our current development trunk into older versions. I'm sure you can see how bad that is.
After getting burned by that, we turned to cvs2svn. It took a long time (8 hours) to convert, but it converted correctly, and you only ever have to do it once.
My advice is to convert your repository, then check out random versions from both CVS and git, then run a diff on all the branches of importance. I wrote a script to do it for all branches and tags because I got burned the first time.
Some of our submodules are 20 times bigger than the Linux kernel and there is no way to subdivide them more than that. Our source base really is that big.
Let me guess... that's Windows Vista ;)
Although hard to mess up the remote copy, messing up your local copy was much easier.
Can't find the quote from Tom Lord (GNU Arch (tla) author, one of the first DVCS), but he was saying something like: in centralized systems, only admins have full power of the versioning, normal users are treated like economy class.
After migration from centralized system to decentralized, one has to stop for a moment and realize that now everything can be done, everything is possible: there are no more big brother behind your back. This is great power and at the same time great responsibility. But thanks to the fact that you ruin only your local sandbox, that "great responsibility" bit can be easily ignored, leaving you only with "great power."
For all the dumping Linus does on Subversion/Perforce and its ilk, they are easy to understand and it's basically always clear what you're doing.
Can't tell for SVN/Perforce, but I can tell for some other centralized systems. It is not so very clear what you are doing there either. Most centralized systems have heaps of scripts running server-side which might actually recast any command you are issuing into something completely different.
But as I have mentioned above, in centralized systems you can do much much less with your repository. Decentralized systems provide much more functionality and that gives rise to the confusion. It's only natural.
To me personally, main advantage of systems like Git or HG or Arch is that there is literally no administrative overhead. (Well, truth to be told, Arch has some.) If you have well organized development with many people involved, then the overhead of setting up and maintaining centralized repository isn't that great. But in my case of lone hobby developer, set up of SVN server, integration with Apache - are all just time wasters. I have started reading SVN documentation but it was already too late in SVN life cycle and documentation became very very fat. But with Git all I need to do to start new project is "mkdir fancy-project; cd !$; git init" and then just move files over. And, most importantly, performing backup is as easy as "git push".
All hope abandon ye who enter here.
Funny the OP only mentioned two projects and one is only planning. Sometimes /. can be a bigger hype machine than money grabbing corps. that we all love to bash.
Who wants to use a tool with crap IDE integration?
Many of us develop on Windows, pushing out code to Linux platforms. Git just isn't an option. Poor support for IDEs, especially Eclipse.
Bazaar has been working great for me. Used Mercurial with success as well.
I've been using git personally for about a year now and have finally reached the point where I am ready to get the rest of my group to adopt it for our work. The tool I am recommending to help with the early git learning curve is Easy Git, http://www.gnome.org/~newren/eg/. Easy Git (eg) is a very thin wrapper around git. It provides clear and suggestions for git usage. Unlike other porcelains, you can trivially switch between eg and git at any time. I think Easy Git can improve the initial git experience for many potential git users.
The Perl foundation's move to Git took so long primarily because they had to gather decades of history from scattered sources: "Some of the patch sets were apparently recovered from old hard drives".
For instance, the MySQL project moved to Bazaar last year, apparently very smoothly. Getting started with Bazaar for MySQL.
Dr Superlove 300ml. I use my powers for awesome
I doubt that BitKeeper is as good as git technically, but it's irrelevant. I remember the BitKeeper debacle and I read a lot of posts by its author. Based on that, I'd use Visual Source Safe first, and I imagine a lot of others feel the same way.
Beyond that, if you look at the git lists and pace of development, it's clearly vibrant. Without looking at the website, I'm not even sure whether BK is still in business. Your post is the first time in years I've ever heard anyone say that they're using it.
"Not an actor, but he plays one on TV."
Neither worked on my 18 yr old CVS repo (that was populated with 7 yr old RCS files). What I did find was fromcvs. I found a couple of bugs, with the author fixed very quickly. It is also fast. My 3.5G CVS repo was converted in about an hour. Both of the others took 10+ hours (and didn't produce usable output). The biggest reason I love it: it allows incremental updates from CVS to GIT. You can run it any number of times and it imports the new stuff. You do need to leave the git repo you are importing into alone (no commits other than the import commits).
I still have more testing to do before we go live, but it's looking very, very nice.
You are speaking to the concept of SVN "hooks" (which which is wanted in Git although I don't think anyone's gotten them to work) or just plain FUD. Triggers are used to spawn other processes for alerts, snapshots, builds, or whatever your heart desires. To what purpose would you write "heaps" of scripts to avoid simple version tracking for some alternate purpose? Validation? And who the hell is allowed to checkout or commit, but doesn't know how their versioning works? It defeats the purpose. If you try to use Git/SVN/CVS as your build tool, it won't work, so please enlighten me to who is doing it (checkouts to a web directory is not a build).
I *have* seen hooks that modify the commit message with a timestamp, committer and sourcemachine, send out emails, but nothing more complicated is worth it.
Often wrong but never in doubt.
I am Jack9.
Everyone knows me.
At work we're trying to get all our our repos moved to Git. We moved off of CVS to SVN a year or so (which was a huge improvement), but now that all of the non-programmers in the office are used to using TortoiseSVN, lack of a good windows GUI for Git has been a bit of a roadblock.
The msysgit folks started work on Tortoise-inspired GitCheetah GUI, but that project basically fizzled out. Lots of people wanted a Windows GUI, but no one had both the resources and drive to step up and do it.
Then, exactly two months ago, Frank Li started working on TortoiseGit. From what I can tell, this is a fork of TortoiseSVN with most of the Subversion guts pulled out and replaced with git commands. TortoiseGit is not done yet: 'git add' has some issues, Submodules don't seem to work at all, etc..., but development on the tool is in high gear and the primary developer is going the extra mile to help users.
If you're looking to deploy tools right now, gitk is a bit more powerful than the log in TortoiseGit, but might be more confusing for naive users.
coding is life
Then such hooks are neat. It also gives possibility to connect one tool to another like adding the commit message to the issue (and close it) in issue-trackers and like bugzilla. Unix strength is to combine different, small, components to something bigger, so there is some justification to the hooks.
Note to self: Make a sig
The thing I don't understand about any distributed VCS is how (for example) others could pull stuff from my repository if I don't have a static IP. Also note that I don't mean "don't have a static IP" only in the usual sense of "having a dynamic IP at home": I also mean in the sense that my development machine is my laptop and I often work at coffee shops and other places and so I'm often behind NATs.
If you reply, do so only to what I explicitly wrote. If I didn't write it, don't assume or infer it.
I curse more when I use git than when I use Windoz (and those are the only times I curse). Git's design is really that bad (from a user perspective).
Git is fully distributed (with no "authoritative" source), but it doesn't give you any tools understand/manage the distribution of files. If you have a work group with more than a few people, you are constantly asking what repo (and what access method to it), what branch, and what (bombastically long) revision. It's fine for 1-2 people, but then any version control system is fine for a small enough group.
The documentation helps little. When you do "git help merge", you don't @#$@# care that this is the front end to multiple merge methods. You just want the stupid thing to work. If it's a special case, then you'll look for an advanced technique; but you are stuck reading through all this crap trying to figure out what really matters. No offense to the people working on git docs. It used to be awful, now it just sucks. The problem is more in the user interface design than the docs.
There are over 100 git commands, and a command can do radically different things depending the the switches and target syntax. It's more confusing than any other revision control system that I have worked with.
I use git because I have to, not because I want to (like Windoz). After using it for months, I still routinely get stuck trying to figure out the right mix of commands, arguments, and target syntax needed to get common things done.
Git can do some (nice) things that subversion can't, but it creates so many problems that you haven't gained anything.
I've heard good things about mecurial and bazaar. I wouldn't recommend git to anyone I liked (but it's perfect for perl :-).
I'm using monotone. What I like about it is its utter paranoia about data loss. Even data loss because of lost bits on a hard disk. You just can't symc a broken repository with a working one; bit failures will not spread. That said, it's designed for use in development against a test suite -- there's a procedure whereby automated tests can be used to "certify" particular revisions, so that an actual user of the software under development can just automatically download the last certified revision and use that.
This isn't true if you know what you're doing. No matter how badly you think you messed up your local copy, you can always run a command like git-reflog show --all, and find a "lost" commit, and then tag it or check it out or something. The commit objects aren't destroyed until they expire or you run git-prune or something, so you have lots of time to find something you lost track of.
The complexity of git robs it of quite a bit of the value of it's features. For God only knows what reason, a 5-6 person project that i'm working on is using git instead of subversion, and only the person who setup the project actually has any idea how to use git. The rest of us are just cruising along, not really having any idea of what we are doing with it, and are stopped completely whenever it does anything weird.
It's awesome to have the whole thing where it merges all the changes in a same file together, fairly intelligently, but even the GUI version for Windows has no functional interface for how to deal with conflicts (which should be easily done as a "which bit of code is the proper piece to use here?" instead of jamming diffs into a file. Also, the Windows and Linux versions of GIT have several problems interoperating with each other.
In short, Git appears to have been designed entirely with features in mind, and not one bit of usability for anyone other than Linus himself. It is a nightmare for people who only have the need for version control and a handful of people working together. It reminds me very, very much of early Linux, before anyone else besides Linus had been hacking on it.
"Champagne for my real friends - and real pain for my sham friends!" http://ericblade.postalboard.com/
I currently use Subversion to keep track of my private projects. Nobody else has access to my repository. It's solely so I can track changes I make to my own software. That said, is there an advantage to using git? I like having a central repository because I can start working on some changes to code, and if I don't like them, revert back. I also don't really care much about tagging or branching. Every now and then I'll use a tag if I want to take a project in a drastically new direction, so I can easily go back to the previous "good" version if I want to. That's about it.
So, is there a reason to switch from Subversion? I'm not tied to it at all; I just want to use the tool that's best for me.
Oooo.. dangerous thinking. The complete lack of administrative overhead seems like a great panacea.. until you realise that you are essentially side-stepping any corporate data retention policy, side-stepping the benefits of corporate IT support and data protection policies, and increasing risk of partial data loss. Or are you suggesting that, via forced git pulls from every single developer to every single developer you are thus creating a redundancy strategy better than the typical corporate IT backup/disaster plans? .. so how is it that you are going to force all developers to do a git pull, or at least a push to some central machine on a regular basis without actually implementing *some* sort of IT-supported machinery?
Hi, If you copy or move a file with Eclipse, you LOSE the entire history of that file.
Doing that is just a simple shortcut for the following sequence of actions:
1. "simple file copy" (like a "cp" command, or a drag-n-drop in desktop OSes).
2. DELETE the source. Yup!
3. Add the copy to the repository.
For some of us, keeping the history of every single change since 1-1-1970 is important. But that will be another thread.
I use git for all of my stuff. I'm no expert, but I'm getting comfortable with what I need it for.
My adivce: play with git a lot before doing any production work with it. One highly refreshing thing about git is that you can create and blow away repos with nary a care... it's quick and painless. That being the case, it is the perfect sandbox toy. So think up some scenarios, create some toy repos, and whack away. Then blow the cruft away and do it again. Understand sub projects. Set up a couple or several machines and users and start pushing and pulling willy-nilly and see what happens. It will be fast and easy to do this on toy repos, and you will understand how it is all supposed to work.
Step two is to do some capacity tests.... scriptomatically create some monster size toy repos and see how they peform.
By the end of this, you'll understand git. And all this playing around is much less painful than with any other system I've seen.
Now, if you have an old repo to import, you have another whole batch of experiments to do. Getting all that history over correctly is going to require some research. Git has a lot of functionality -- the current state of the documentation leaves you to do some digging, though.
Oooo.. dangerous thinking. The complete lack of administrative overhead seems like a great panacea.. until you realise that you are essentially side-stepping any corporate data retention policy, side-stepping the benefits of corporate IT support and data protection policies, and increasing risk of partial data loss.
Load of bullocks. I'm working in corporations for past 5 years and yet to see any "benefits of corporate IT support." Corporate IT is generally some bunch of management-ass-lickers. They do not care about mere mortals developers.
As to retention policy and data protection, for past 4(?) years, my $HOME is always and completely backed up - and that's includes all my repos. In fact it is volume over NFS mounted from huge NAS RAID.
Or are you suggesting that, via forced git pulls from every single developer to every single developer you are thus creating a redundancy strategy better than the typical corporate IT backup/disaster plans? ..
You are severely behind times. See above.
so how is it that you are going to force all developers to do a git pull, or at least a push to some central machine on a regular basis without actually implementing *some* sort of IT-supported machinery?
When developer gets assignment (e.g. implement feature), he is also responsible for delivering on the assignment.
In CVS/etc it is check-in to global repository.
In Git this is push into global repository.
Difference? None.
Well, in fact there is one. In CVS/etc developer is responsible for integration of feature with rest of the system. If he wasn't bright enough and f***ed up rest of the system in the process - whole R&D is f***ed up. In Git, "push" remains local to the "global repository" and if somebody broke something, one can always review and reject the pushed changeset - even before anybody can pull it. Or even if you cloned the global repository, you still can remove the changeset locally. In Git there is very little overhead of maintaining repos which work only as staging area: where to others can push and where you (as e.g. release master or tester) can compile/test the changes. After changeset was cleared by release/test teams it can be pushed further into real global repository, where it would be visible by others.
Check that out - "Integration Manager Workflow". This is pretty much ideal workflow, which in past I have seen people numerous times tried to implement using centralized systems. And before DVCS I have seen only one solution which can be called "working."
All hope abandon ye who enter here.
CVS migration works well enough with nice simple CVS trees. Unfortunately the last two jobs I've worked at the CVS tree has not be pristine enough to get through a simple migration. One tree has been hacked up for performance reasons (old branches having pruned out of the tree which causes cvsps to die when it can't find the branch) and the other was so large even a 2gb machine would slow to crawl.
In the first case I wrote scripts to import known labels into git (loosing the changeset data but it wasn't that interesting due to the baseline process). The second case I tweaked parsecvs to work with modern gits as it was the most efficient of the conversion tools.
Hopefully my next job won't involve either of these two CVS failure modes :-)
Alex.
The problem with git or mercurial or any other DVCS is that it's ALL OR NOTHING solution. Let me explain: I can't force our customers to use git or mercurial or bazaar. They already have CVS or SVN or some commercial tool I don't want to mention. So the only way for us to use DVCS is to use both tools at the same time on the same codebase. And this is the point where we can see DVCS shortcomings: tool support.
We are developing a multiplatform code. We are writing it on Linux, but still we have to modify & test it on win32. Would you recommend using git for such a project?
TortoiseGit (the port of Tortoise) isn't quite there yet, and git-cheetah (a recreation from scratch of Tortoise) distinctly less so, but there definitely is an Eclipse plugin, jgit / egit.
git-gui is not that horrible, if you don't want as tight integration.
I don't see any mention of this feature in the comments: git cryptographically signs every commit, so you can tell if there was an error in transmission/storage or if someone has attempted to alter history or file contents. In fact, commits are labeled by their hashes. This is the cool feature that convinces me to stay with it, although I still find it occasionally mysterious; I just continue to assume that my incomplete understanding of its opaque machinations is my fault, and that with continued study all will be clear (even the man pages).
-in-one makes sanest sense, though I'm not certain.
would mean that I could have a super-repo for all of 'em, plus sub-repos for each, so bug-fixes & updates could be local.
I don't know if that makes sense, but considering-the-problem is interesting, and maybe someone else knows the Right Answer?
PS: how come http://darcs.net/ got nuked and only Git is considered, nowadays?
PPS: how come no wordprocessor/docprocessor uses git/darcs as the back-end, to make document evolution better?
( a modified TuxCards would seem to be the ideal case for this )
You might try git-gui for a standalone tool, or egit for an Eclipse plugin.