[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [e4-dev] Using cvs import in therepository/CommonBuildInfrastructure
|
I'll read through that bug later today, so the answer here first.
1) Git is very flexible when it comes to advanced things. Inside a single repository, you can rearrange and edit commits as you like.
If the undesirable changes have been replicated and you still need to rearrange the history of you repository, you can do it anyway. After that people will not be able to pull from you until they catch up, so you need to communicate the changes you did to the community. People will have several options to catch up:
a) if they do not have any local changes, they don't need to do anything (git reset --hard origin/master if they have a local checkout they wish to bring up to date);
b) if they do have local changes, they can apply the same history changes you did (i.e. type the same set of Git commands) locally (which will fix the problem), -or-
c) they can git-cherry-pick their own changes on top of your new HEAD, -or-
d) they can merge with your HEAD, which would leave undesirable commits in their local repositories (but if they only send you patches and do not publish their repositories on the official site, this is not a problem).
Additional notes:
- that Mercurial has less options here, because it does not allow you to independenty change old commits and arrive at the same commit id (thus allowing future work as if nothing happened) after that.
- these history problems are not unique to DVCS; someone can duplicate CVS history too (i.e. a committer via rsync), or can have a working directory with offensive commit in effect
- imagine that you need to delete a historical commit from CVS which touched many files - people do not have any options in that case except to make a patch from their local changes, recheckout and apply the patch.
Summary: removing a commit from all official sources is (more or less) easy (and maybe easier than with CVS), ensuring that a commit cannot appear anywhere is impossible as before.
2) Git works well on all platforms. Windows has a nice mingw-based version which (I believe) is now official. They used to have problems on Windows (ssh-related in particular) when they were based on cygwin and mingw port was immature, but now it works well.
Mac users have absolutely no problems. Many of us are working on a Mac, and, unlike on Windows, we have never even heard of any troubles there.
Of course there may be some cultural differences between users of various platforms. For example, Git likes to use ssh protocol, and to work with ssh without retyping your password you need to set up public key authentication. This is familiar to Linux and Mac developers, but may sound frightening to Windows ones. (The problem should go away with a good Eclipse Git team provider, because Eclipse CVS already knows how to work with SSH, including key management.)
Summary for platform differences: with a decent step-by-step setup instruction, users of every platform can get Git up and running in 10 minutes (without any further differences).
3) Yep, actually the only good VCS integration Eclipse has is CVS. But:
a) It seems possible to work (i.e. check out and commit) on Eclipse projects via git-cvsserver. To dig in the history or branch/merge/tag, you will still need the command line. But hey, in CVS you cannot dig in the history at all (okay, you can, but it's so limited that it almost does not exist), and command-line branching/merging is not that hard. I have limited experience with git-cvsserver, but committing was definitely possible. You can serve your own repository through git-cvsserver, thus allowing both Git command-line and Eclipse CVS usage.
b) It's a shame that Eclipse has such poor VCS support, and while it is sticking to CVS, this is bound to continue.
c) There *is* a VCS provider for Git. I've never tried it, and I know it to be incomplete. If the core team starts using Git, things will improve fast.
Now, the drawbacks (which are kinda easy to overcome) should be weighted against the advantages. And they are:
- reliable history (which can actually answer your questions, not just serve as a backup), which also ends up more granular because people can commit very often (and things like pre-release repo freeze do not have to stop the work and do not cause huge commits afterwards)
- easy branching *and* merging (it's okay to make a branch for each change you work on, it's okay to branch someone else's work and stay on top of it)
- ability to work offline (important to some people)
- flexible workflow (you can have a central repository, or you can have repository-per-person, or you can mix these approaches; you can do things like rsync, serving your repos via http, you can zip the whole repository and send by email, etc)
- easier contribution process (just ask someone to pull from you), especially if someone puts your repository on GitHub, which people will definitely do
- more flexibility for business usage (people can keep a local clone of your repository, keep a local branch with changes tailored to their environment, etc)
- scriptability and "hand-viewability/modifiability" to serve advanced needs / emergency cases (the whole history has a simple zipped textual format, stored in files named after SHA1 of their content)
Sure enough switching tools is a stress and involves a learning curve. However using CVS is like saying "we'll develop e4 in C++ because who needs this fancy Java stuff". You have to switch tools some day, and distributed version control has been around for years to consider it mature enough.
2008/11/12 Oberhuber, Martin
<Martin.Oberhuber@xxxxxxxxxxxxx>
Would you mind sharing your experience here as well:
As far as I've been told, the drawbacks of using git
directly are
-
As for any distributed repository system, you cannot
"recall" a
commit once you made it and it's bee replicated.
This presents problems in
terms of IP / Copyright.
Centralised systems like CVS allow deleting a
revision
in case you notice after-the-fact that you committed
something
that violates IP in any way.
-
I've been told that git works nicely on Linux but is problematic
on
other OS's (Windows, Mac).
-
The git Eclipse integration seems not quite production quality
yet
(hence my original idea of presenting it as a cvs server -- but
that
doesn't support "tag" and "branch" which are essential
IMO.
--
Andrey.
