Sorry for the slow reply > Anyway on to the complaints: > 1) Hate Git because it puts a lot of scripts a lot of places. >
What packaging system are you using? I'm using gentoo, haven't examined the upstream source, but at least on my system I get: - couple of binaries in /usr/bin - almost everything else in /usr/libexec/git-core/ - some documentation files in /usr/share (optional) - *IF* you install perl/python etc support then you will get some files in their modules directory. At least on my system this is an optional dependency though However, given that it's all managed by your packaging system why do you care anyway? If you install from source then I agree this isn't desirable... > 2) Distrust the decentralized development model > OK, this is not unreasonable, but ironically the one we need to help you get confident in because it's exactly where a dvcs scores highest! I *think* your fear is something similar to having lots of local working directories and forever being unsure which one has the latest code in? Hey we all did something similar before we discovered cvs etc and at least once picked the wrong "myproject.yyyymmdd" directory to start hacking on and wasted a load of time. In fact whilst you have a lot of flexibility to find something which works best for you, the reality is that you are likely to end up with something which feels rather like the old "checkout from master, hack, checkin" model that you are using from svn today. In fact the key difference is simply that git allows *lots* of people (not just core) to work using a similar strategy. ie the svn way of working feels nice, we just need to extend it to everyone, everywhere and not just the core commiters of the project So *likely* you will be most comfortable with a process which is something like: - Clone master git repo - Create a branch locally to hold any changes you make over the next 1 hour (or whatever) you have to develop. - Generally checkin changes with something that will feel like wild abandon if you are coming from svn. Seriously, go wild, checkin much smaller changes with good descriptions - Eventually you get somewhere that feels like you want to show the world so you punch "git rebase -i" and this will tidy up your branch, allow you to remove completely redundant commits, change messages, merge commits together (or break them up) - Use "git push" to push your development branch back to SF or wherever hosts your world readable repo Notice how git gives you massively more granularity than before. Right now you probably wouldn't create a bunch of branches just to hold this afternoons work? Notice also how git just wants a bunch of commits and we can then massage these into better shape before we show them to the world? Also it's not obvious, but you can very easily pull 10 branches into a master branch - why? - well this allows you to create a branch *per feature* for dev purposes and then pull all that back together again later! I just want to digress on the last point: git et al, give you the ability to create a branch to say "refactor authentication" and you might hack on that in parallel for the next 3 years, never once folding the code into the upstream. However, some X years later of hacking and you can just hit that branch with some git magic and extract the relevant commits to pull upstream into some other branch. It's a HUGE increase in flexibility that you can run multiple parallel branches to the main development (eg one per new feature) and git gives you the tools to make this work and make it easy (in particular it will pull in all the changes from various other branches, whilst still tracking only the new feature changes in *this* branch, ie you can stay up to date with HEAD while you hack on that new feature!) OK, so in conclusion, the dvcs is not about having a huge bunch of working copies lying around and never being sure which is the most recent. In fact *you* still work pretty much exactly the same. The "D" bit is really more about how these marvellous systems track branches and effectively allow you to basically break your code up into a series of patches, each of which can be re-arranged, re-ordered, split up into arbitrary branches, etc, etc. The point is more that with this level of flexibility comes new ways of working, such as using lots of branches, smaller commits and being able to push those commits around in fairly arbitrary ways. This happens to be extremely useful in various scenarios including the "multi-master repo" situation, but that's not it's only purpose Have a look at some of the other tools also. I think git is probably the one you will pick to use, but examining the way other dvcs systems work is quite an eye opener, eg DARCS has this amazing mathematical logic behind it, patchwork from gnu is similarly clever, git treats everything as a blob, but in contrast I believe mercurial/bazaar track code patches (?). It's quite instructive looking at the theory because you get an idea on the various tradeoffs in design and also you stop getting bogged down in the details of the command line params and start thinking of it as a very clever tool and "how can I leverage this to achieve XYZ" > Also, I am a little bit concerned about the possibilities of getting a > dcvs-based solution wrong. Since everything is disconnected, with > lots of different branches, it seems like it may be very easy to screw > something up, Actually, it's quite the opposite, but I think you need to play with this a bit, or read around, before you are going to believe me. You don't usually use git as a maze of little hard to track branches and clones, usually quite the opposite... > like issue a release from the wrong branch. Again, suggest that you will likely end up with a way of working that makes this quite difficult. eg the two main development paths are usually: - master is dirty development only branch (or multiple branches, etc). Commits are literally cherry picked *back* into the RELEASE_XYZ branch and the release branch becomes ultra stable (I don't like this approach, but...) - master is dirty development, but periodically there is a push to get it stable and fork it off to release it. Once the branch gets reasonably close to release it's usually forked into RELEASE_XYZ and master reverts to being development only again, BUT commits which fix bugs and stable the release can be easily plucked out of master and into the release branch. (I think this suits my way of working best, it's probably also how you use svn) Usually with the second option you additionally use feature branches to work on stuff which is very new without destabilising master, so in fact you can do a kind of hybrid approach. Usually you hack on a feature branch (or 5) and then when that feature is good enough to be seen you just merge it into master and carry on from there. ie basically you are using your svn development model, but you also benefit from "feature branches" that make it easy to hack on new stuff > I am therefore going to suggest a solution: > > 1) Keep SVN as the master repository for the purpose of official > project releases. Keep commit access fairly strongly restricted. > 2) Add an official Git repository with core management regarding > pushing patch sets into svn. This could be done in one of a few ways. > 3) Currently we already accept patches against either repo. This > wouldn't change. > This strategy can work, but it requires a fair bit of effort to maintain and splits the vcs user experience. Also you are testing and possibly stressing the git to svn link and whilst I have found it to work fairly well, you have now placed the quality of that conduit as a direct blocker on the project being able to continue to accept patches... If you hit a hurdle with the conduit then you need to down tools until it's fixed. Also git offers basically a superset of svn so at best you are just making the repo available to another set of tools, there is no reason to go multi-master with both svn AND git since svn has no multi-master option and it's just a case of submitting patches (as text), if you are outside the core committing team... I would suggest you go git (or bzr or whatever) only and drop svn. It can work, but you have just added a whole chunk of maintenance and risk for likely very little benefit to the project Good luck Ed W ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Ledger-smb-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
