Am Montag, 20. Juni 2011, 21:22:06 schrieb Andrew: > 20.06.2011 18:53, KP Kirchdoerfer пишет: > > Ok; Mikes proposal sounds reasoanble and I think a repository each leaf > > project is a way to go. > > In the repository we can one or more directories := different major > > versions of a project. In the past Bering-uClibc major version changed > > mostly when uClibc changed significantly and broke binary compatibility, > > the second version number was reserved for major updates, esp. kernel > > updates, the third for fixes. The last two can be handled with branching > > in the directory. > > I read the man page for "git rebase" and it talks about branches > > Bering-Uclibc 5 will introduce maor changes (uClibc, buildtool), but as > > long as it's an evolutionary process and the developers agree to build > > together a new version while maintaining the old. *If* there will be > > disagreement about the future, Bering-uClibc5 may be forked and put into > > a new repository as a completly different project. Like Bering-uClibc > > was a fork of Bering, and therefor a new LEAF project. > > > > > > So we'll have the repositories: > > leaf/leaf > > leaf/Bering (if there would be further development) > > leaf/Bering-uClibc > > leaf/packages (for binaries) > > ... > > > > in the repository leaf/bering-uclibc we could have the directories > > bering-uclibc4 (today buildtool) > > bering-uclibc5 > > bering-uclibc-mips > > ... > > > > as I said as long as the developers agree to work together and therefor > > should be interested to push and pull also from new directories. > > I think that directories inside repos are actually unneeded. Branches > are IMHO enough good. And switching between them is easy (git checkout > branchname). > Additional directories should add just headache on importing fixes from > stable branch to experimental + wasting of space on HDD for most > developers who works on one branch, and no profit at all. If somebody > wants to have 2 or more independent source trees - he may just create > new directory and clone repository into it, then switch to desired > branch. And I see only one con of this solution - additional overhead > for duplicated .git directory (which isn't too big - now it's near 350M > which is 20 times smaller than fully compiled building environment & > packages, and comparable to sources size), but this solution has such > advantages as completely independent work on projects, w/o need to > checkout each time new branch and no troubles with rolling back to one > of earlier commits. > > > In the leaf/bering-uclibc/bering-uclibc4 directory we can have two or > > three remote branches > > master with the latest development tree leading to 4.1 or whatever > > 4_0_1 with fixes and security updates for 4.0 > > later 4_1_1 with fixes for 4.1 > > I'm not shure about remote branches (how to tag, when to delete...), what > > be in the end the stable versions (4.0 or 4.0.1) once we stop working on > > 4.0.x...? > > But I guess this can be figured out and learned in the process. > > Just switch to commit that is tagged as release, then create new branch > and add all modifications for it (AFAIK you even can merge just some > selected commits or commits range from one branch into another one). > And I think that branch deletion is really unneeded (maybe except very > experimental branches that becomes dead and has no practical interest)
Thx for pointer, sounds good. I'll try once we have nailed down the repositories. > > If we do agree, I'm creating the new bering-uclibc repository and > > everyone should have a clean local git so moving from > > leaf/leaf/buildtool to leaf/bering-uclibc/bering-uclibc4 does not harm > > too much. (Though I'm not shure if this works as seamless as I hope.) > > > > kp > > I vote for excluding unneeded entities (project directories) from > development process to avoid troubles in future. Git brahches are enough > good for projects separating. Other opinions? Fien with me. I just want to outline in my notes above that something "above" branches, and more "lightweight" than respositories can be done with directories. If we can live woithout directories and will able to manage development in branches, so much better. 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
