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) > 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? ------------------------------------------------------------------------------ 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
