... and comments are disabled?
... and comments are disabled?
My 5 cent: Use svn and svn:externals instead of git, if you don't need the distributed functionality that git offers (others will strongly disagree).
Unfortunately I have no suggestion regarding a migration of the existing history. When we did that 9 years ago, we started from scratch. Jedi VCS is written in Delphi, so it probably would be possible to write a program for that, using the source.
Originally shared by Hubert Bannwarth
From JediVcs to Git
I use JediVcs to manage the Delphi source files for several years, There are several projects with a lot of common files. As my team grows up, JediVcs becomes complicated to use and I’m looking for a move to Git.
the JediVcs is project based and the modules can be shared between several projects if they are located in the same directory or not.
Git on the other hand is directory based and there is a way to use subprojects.
I do not want to loose all the 15 years history for my source files .
So far, my options are :
let the history in a jvcs repository and start Git from scratch (not interesting for me as I will have two repositories).
extract the history from jvcs and import to Git per directory and use subprojects (not sure about using subprojects in Git when working on it daily)
us only one project including all subdirectories (except external libraries like jvcl) and import the history
My favorite options is the last one but I wonder if someone has already done something similar.
Do you have some ideas, or recommendations for this migration ?
My 5 cent: Use svn and svn:externals instead of git, if you don't need the distributed functionality that git offers (others will strongly disagree).
Unfortunately I have no suggestion regarding a migration of the existing history. When we did that 9 years ago, we started from scratch. Jedi VCS is written in Delphi, so it probably would be possible to write a program for that, using the source.
Originally shared by Hubert Bannwarth
From JediVcs to Git
I use JediVcs to manage the Delphi source files for several years, There are several projects with a lot of common files. As my team grows up, JediVcs becomes complicated to use and I’m looking for a move to Git.
the JediVcs is project based and the modules can be shared between several projects if they are located in the same directory or not.
Git on the other hand is directory based and there is a way to use subprojects.
I do not want to loose all the 15 years history for my source files .
So far, my options are :
let the history in a jvcs repository and start Git from scratch (not interesting for me as I will have two repositories).
extract the history from jvcs and import to Git per directory and use subprojects (not sure about using subprojects in Git when working on it daily)
us only one project including all subdirectories (except external libraries like jvcl) and import the history
My favorite options is the last one but I wonder if someone has already done something similar.
Do you have some ideas, or recommendations for this migration ?
Give a try to Mercurial to Fossil - git is difficult to setup and use. A DVCS is much more powerful than svn, which is IMHO deprecated and slow, with huge number of files. You can put all your files in a single DVCS repository, and won't fear creating a branch.
ReplyDeleteThe later (Fossil) is awesome: to install a server, it is just a single cgi executable, or to install a client, just the same executable. Performance is awesome, and you got timeline, tickets, wiki, and web interface built-in. See e.g.http://fossil-scm.org/ and e.g. http://synopse.info/fossil/timeline for hosting a huge Delphi project.
A. Bouchez git server https://bonobogitserver.com/ is simple to setup and use :)
ReplyDeleteI am a little bit concerned about his wish to not lose all history. I can understand that he would want milestones (such as specific releases) - but does he really need all of it? Unless there is a migration tool from JVCS to , he will still lose the commit messages.
ReplyDeleteThe way I see it, he really has only one path for doing this.
Plan out how the new repository shall be organized.
How many projects really depends on the granularity needed. Unless there are tons of shared code between the projects - I'd say several sub projects is a better option than a huge master project.
Extract the milestone versions to keep, in chronological order into the appropriate directories, and commit/push, then pull to tag or branch in the main git repository - repeat for each subproject/version.
Don't bother trying to migrate the history. It won't migrate well. Keep the old system around for reference. After a few months you'll hardly ever look at it.
ReplyDeleteIIRC, Roman Kassebaum has made a migration from JediVCS to Mercurial recently. Perhaps he can give some advice here.
ReplyDeleteUwe Raabe
ReplyDeleteYes that's true. Uwe Schuster gave me a small tool that can convert JediVCS repos to hg. I used it some months ago for a huge project with several JEDI repos.
A conversion from hg to git would be easy.
David : we need the history, sometimes we have to look at some older commits.
ReplyDeleteSorry for the comments, enabled now, thanks Thomas
ReplyDeleteA. Bouchez You're kidding, right? Because you're wrong on pretty much every point.
ReplyDeleteSVN is much more powerful than a DVCS, because it actually works for its intended purpose. DVCS is "powerful" in the way NoSQL is "powerful": for a massive-scale project that's far bigger than the one you actually have, you might need it, but otherwise it just causes more headaches than it's worth because it can't do basic functionality right, because it has to sacrifice it in order to get massive scalability to work.
The most fundamental VCS operations are pushing code to the repository and retrieving code from the repository. On this, SVN wins hands down in every way. In SVN, a push and a pull are a single operation each. In a DVCS, they're multiple steps even under the best of conditions, and it can easily explode into ridiculously a complex series of convoluted steps. In SVN, when you pull changes, you only get what you care about, which is fast. In DVCS, when you pull changes, you get all changes to all branches, even ones you're not working on, which can be agonizingly slow.
"You can put all your files in a single DVCS repository," unless, of course, some of those files are binaries rather than text. DVCSs are infamous for choking on those. SVN handles them just fine.
"...and won't fear creating a branch." Huh? Who fears creating a branch in SVN? If anything, I fear branches in DVCS because it means pulling changes will take even longer, pulling in even more irrelevant crap that has nothing to do with what I'm working on!
Mason Wheeler
ReplyDelete"SVN is much more powerful than a DVCS, because it actually works for its intended purpose."
We already had a long discussion about this topic but I simply say no it is not!
Hubert Bannwarth You don't lose the history because you move to a new system. The old system can still exist. That's what we did. Far easier.
ReplyDeleteDavid Heffernan Yes, I know but it is easier to make a diff and search for commit comments on the same repository rather than using two systems.
ReplyDeleteDavid Heffernan That is not always the case. I moved my code from RCS, CVS, PVCS, Team Coherence, SVN to currently HG. It would be a nightmare to setup all those systems (especially those server systems like PVCS, TC and SVN) on every new system I move to. I am not sure if these are actually available for modern Windows.
ReplyDeleteMason Wheeler On the other hand SVN is a pain when it comes to merging, and it is agonizingly slow when swiching branches (as in several orders of magnitude slower). Annotating can take 10+ minutes on some of our source files, git does it in a few seconds on the same files.
ReplyDeleteAs for pushing and pulling exploding into convoluted steps, well I've never experienced that, sounds like what happens when moving against the grain.
I will say that git is not user friendly, and due to that I'm not a huge fan, but every day I use SVN at work I wish we used a sensible DVCS.
Mason Wheeler I'm not kidding. I used SVN a lot, and would never go back to it. Fossil is a DVCS, but you could easily use it as a regular centralized repository, with the advantage of having a full local copy. See the "autosynch" feature at http://fossil-scm.org/index.html/doc/trunk/www/concepts.wiki#workflow
ReplyDeleteWith fossil, you can still prepare all your commits, and push them to the server when needed (e.g. when you are back online). Pretty convenient, and not available with SVN AFAIK.
Git works great, but it may be over-complicated for most simple projects, smaller than the Linux kernel. ;) For such projects, HG or Fossil are good alternatives.
About binaries, I do not see where your statement about DVCS being "infamous" comes from. I never saw any problem with Fossil or Git and binaries.
A. Bouchez Mercurial didn't handle large binaries very well, treating them the same as other files (byte diff). They've introduced some extra functionality for those some time ago, but last I checked had to be explicitly used. Git is better in this regard.
ReplyDeleteJust to explain my needs, I do want to migrate to Git as I have already several projects hosted on our Git server (Titanium, PHP, RoR). the only question was how to migrate, what is the best option.
ReplyDeleteLars Fosdal I did look at the Jvcs database and It seems to be possible to extract all the commit comment, not only the milestones
Roman Kassebaum can you share the tool or do I have to ask Uwe Schuster ?
Asbjørn Heid I've never annotated on Git, so I can't comment on that, but on Mercurial it takes longer than SVN ever did, local repository notwithstanding! (Not to mention the way its big mess of interleaved branches and merges makes it exponentially more difficult to answer the fundamental question of annotation: "where did this code come from?")
ReplyDeleteWRT convoluted step explosion, see http://tech.turbu-rpg.com/657/i-am-officially-sick-of-dvcs for my experience on the subject. (Just one of many, I might add. I see stupid crap like this on a regular basis.)
A. Bouchez Yeah, SVN doesn't do the "offline version control" thing, because "offline" is not version control. Version control is, by definition, a collaborative, versioned backup system. If it's still on your computer and will thus go down with the ship if your system is lost or destroyed, it's not a backup.
ReplyDeleteWRT binaries, simply Google "git binary files" or "hg binary files" and look at what comes up...
Mason Wheeler I don't have any experience with similarly large files with long history in Mercurial, but for the projects I've used it it was about as fast as Git (ie at least an order of magnitude faster than SVN). Annotating any file in our repo with svn does not take less than 10 seconds.
ReplyDeleteAnd I've never experienced any issues finding out where the code came from when using annotate (or similar) with Mercurial or Git. In fact I have the complete opposite experience, because SVN only has cherry-picking. I see some commit yeah fine, but I can't see where it came from. That is, our tool has some option to show merge arrows but after leaving it running for 15 minutes I gave up on it.
As for the link you posted, that mess was entirely self-inflicted and expected because you treated Mercurial as if it was SVN. Like I said, going against the grain.
While shelving might work, the easier and safer way, in my experience, is to just do a local clone and fix the bug there, and then push back to the central repo (and of course pull -u on the repo you were originally working on).
I use this method with SVN as well, mostly because it takes so long to switch branches it's faster to just keep 5-6 repos around in different branches, but also because it's safer (since I can actually test my changes).
edit: clarification on annotate speed.
Mason Wheeler I will say however that neither Mercurial or Git is perfect in my view, so I'm not fanatical about them.
ReplyDeleteI think Git has a really solid core but has a certified terrible interface, spewing internals in your face. Some GUIs tries to put lipstick on it but it doesn't help much. Mercurial has a really nice interface for the most part, but it has a weaker core, at least back when I used it heavily a few years ago, and some design choices I'm not super fond of.
SVN isn't terribad, I just find that it's not very good either. It gets the job done, but it feels like it's due to an accidental alignment of features than anything else.
Asbjørn Heid So now you're adding even more unnecessary steps. By your logic, one should create a new branch, switch to it, make their code changes, commit, then merge the branch, switch back to the original, and close/delete the old branch, for every single issue, in order to avoid merging problems on a system that advertises painless merges compared to SVN!
ReplyDeleteDo you seriously not see how insanely, unnecessarily convoluted that all is?
Mason Wheeler That's not what I said, I never mentioned branches.
ReplyDeleteAnyway, if you want to live on the edge (which I guess you do since you long for mixing revisions in your working copy), then when you tried to push your fix and it got rejected, you could have just rolled back your bugfix commit, pulled, updated, committed your bugfix and pushed that. All within the same working directory.
However I prefer the local clone variant because it's safer, and not much slower.
Hubert Bannwarth
ReplyDeleteYou should ask Uwe Schuster.
I don't understand whats so hard to grok about git for the life of me. I love it. Its not hard to install. at least on a mac.
ReplyDeleteAsbjørn Heid So then what is a "local clone"? I already have a local clone: the local repository. AFAIK the only way to "clone" it again is to branch. (I assume you're not saying I need to check out another entire copy of the repository for each issue!)
ReplyDeleteMason Wheeler I do mean a full clone, but from the already local repository. If the project is small the clone can be disposable, otherwise I'd just keep the local clone around for the next time I have to do emergency fixes.
ReplyDeleteAs I said I do this with SVN as well, but due to the horrible switching speed I got 5-6 copies and not just one.
Mason Wheeler I used this "offline" feature to work e.g. from a plane, or when I'm out of GPRS/WIFI, by preparing several commits. The main server is still used as main "backup". But the smaller granularity of commits, the better.
ReplyDeleteI guess you did not notice the "autosynch" feature of http://fossil-scm.org/index.html/doc/trunk/www/concepts.wiki#workflow which allows the best of SVN and DVCS, with a little amazing tool. You are never forced to use branches with fossil, but if you need them, they are pretty easy to work with.
A. Bouchez "the smaller granularity of commits, the better." Why? What is it about small-sized commits that makes them inherently good?
ReplyDeleteMason Wheeler I'm not fanatical about small commits either but it does make bisection a lot more powerful, when tracking down a bug.
ReplyDeleteMason Wheeler I think is always wrong to start religious wars... but just to simply quote Linus Torvalds: "[...] When I say I hate CVS with a passion, I have to also say that if there any SVN users (Subversion users) in the audience, you might want to leave. Because my hatred of CVS has meant that I see Subversion as being the most pointless project ever started, because the whole slogan for the Subversion for a while was 'CVS done right' or something like that. And if you start with that kind of slogan, there is nowhere you can go. It's like, there is no way to do CVS right. https://git.wiki.kernel.org/index.php/LinusTalk200705Transcript
ReplyDeleteFrom my experience: Git has one of the most steepest learning curves I know of. But this is due to the fact that it requires you to perform a complete mental shift. I've used VCS then SVN for years, so I know very well what I'm talking about. Then I started learning Git. It tooks me about 3 years to grasp every intricacies of it. But now I will never look back at whatever. Every once in a while I have a discussion with other programmers that advocates the use of Subversion over Git: I simply answer: this is a problem with your technical debt, thus it is not a Git problem.
Fabio VITALE Yes, I would certainly expect the guy who created Git specifically because other VCSs didn't fit the needs of his own pet project to trash other VCSs, but you can hardly hold that up as an objective example for precisely that reason. Projects that look a lot like Linux--massive in scope, heavily forked, with an enormous, widely-distributed development team--benefit from all the extra complexity the DVCS paradigm imposes. But is anyone here actually working on such a project?
ReplyDeleteMason Wheeler actuality other projects profit from the DVCS paradigm: All those that accept contributions from developers who don't have direct write access to the main repository. It's much easier to add patches if the VCS has good support for merging and also automatically adds the commit message of the original developer.
ReplyDeleteI wouldn't call GExperts massive in scope and heavily forked. And having any development team would be really nice for a change. But it's only a few people contributing to it, and Eric an me (mostly me) integrating those contributions. And that can be a real pain.
Having said that: I definitely prefer svn over git or hg for the kind of development I do at work.