Hi Erich; Am Sonntag, 19. Juni 2011, 18:29:26 schrieb Erich Titl: > on 19.06.2011 17:31, Andrew wrote: > > 19.06.2011 17:20, Erich Titl пишет: > >> Hi Andrew > >> > >> on 19.06.2011 16:01, Andrew wrote: > >>> 19.06.2011 16:48, Erich Titl пишет: > >> ... > > ... > > > Removing staging/i486-pc-linux-uclibc (and possible i486-* in > > staging/bin) doesn't help for you? > > Maybe it would, just that this is not clear at the moment, as buildtool > is fouled up and requires many hours of recompile, hardly what I would > call a seamless operation.
I understand your frustation today, but I'm confident the git repositories and our knowledge will improve over time, so accidents like you had will vanish. > >> Again, very frustrating. We need an environment which does not have to > >> be rebuilt just because the kernel has changed. > >> > >> - a stable compile environment is mandatory > >> - stable libraries (uClibc) > >> - dependencies must be obeyed, e.g. dependencies of libraries from the > >> kernel > >> > >> Maybe these are all legacy issues, still IMHO not acceptable and maybe > >> this is the reason why we have so little contribution. > > > > Toolchain and buildtool needs a lot of work - now toolchain is slightly > > modified variant of 3.x branch (just updated and with small patches), > > with a lot of ugly hacks and magic tricks. This will be rewritten - but > > some later, now I haven't enough time (it may require 1-2 weeks). > > Maybe there is place for discussion in this area. I would like to see > much of all those perl dirty tricks disappear altogether. > > >> As to GIT, what is the easiest way to avoid conflicting changes in the > >> repository? Creating a local branch of main/master.... whatever? Who > >> does the merge and resolves conflicts? > > > > Conflicts are resolved better than in CVS - GIT doesn't allow you to > > overwrite file modified by somebody else. > > But sometimes this is the goal. I guess Andrews statement misses "automatically" before "overwrite". > And merge is automatically > > > done if you > > Right, but that is not alway what one wants. > >> How can we, for example, have most packages in the main branch and a few > >> in another, then create objects from both? > > > > New branch is based on main branch (or other remote/local branch). So if > > there are changes in main branch - you can do rebase for your local > > branch, to import changes into your branch. > > So if I just create a branch, what will be contained in that branch and > how is it synchronized to the rest of the tree. How do I just touch a > single component and still get all the updates from others in the game, > while not working in the same branch anymore? The whole concept is > really different from all the other versioning tools I have seen and > that includes SCCS, RCS, CVS and SVC. I am under the impression to have > completely lost control about the versioning tool, instead of gaining > control over the project. :)) Have you had look into Davids notes about using git? http://sourceforge.net/apps/mediawiki/leaf/index.php?title=Bering-uClibc_4.x_- _Developer_Guide_-_Hints_and_Tips_for_using_Git_SCM It helped me a lot esp. with local branches. In fact I was puzzled to see files added, removed or updated on my local disk just with "git checkout <branch>" - I was under the impression I've lost control over my harddisk :) kp ------------------------------------------------------------------------------ EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev _______________________________________________ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
