Create branch.

  • Thread starter Thread starter Akari
  • Start date Start date
Status
Not open for further replies.
A

Akari

Guest
I think we need to create few brunches.

1) Trunk are always stable working version. Merged from branches from time to time.
2) Branch for Field module development.
3) Branch for Worldmap module development.
4) Branch for Q-Gears core development.

How this work. Each developer work with it's own branch. And when whole task that developer was trying to acomplish finished he merge it with trunk. And update his own branch from trunk. This way we always have complete and compilable version in trunk.
 
I think we need to create few brunches.

1) Trunk are always stable working version. Merged from branches from time to time.
2) Branch for Field module development.
3) Branch for Worldmap module development.
4) Branch for Q-Gears core development.

How this work. Each developer work with it's own branch. And when whole task that developer was trying to acomplish finished he merge it with trunk. And update his own branch from trunk. This way we always have complete and compilable version in trunk.
Click to expand...
Doh. I love it, but I can't help but be already afraid of the difficulty we will face when merging into the trunk  :-D
 
I think we need to create few brunches.

1) Trunk are always stable working version. Merged from branches from time to time.
2) Branch for Field module development.
3) Branch for Worldmap module development.
4) Branch for Q-Gears core development.

How this work. Each developer work with it's own branch. And when whole task that developer was trying to acomplish finished he merge it with trunk. And update his own branch from trunk. This way we always have complete and compilable version in trunk.
Click to expand...
Doh. I love it, but I can't help but be already afraid of the difficulty we will face when merging into the trunk  :-D
Click to expand...
This will be easy if we will plan common classes (not only ones that shared between games but the one that shared between moduls too) and will not create things "just to make thing works". Planning will help. Each common class needs to be planned first and everyone should use it properly. New features can be discussed and implemented later, for time being classes that used in module can be kept in module directory.
 
Hmmmm.

I don't like this idea. If you code is screwing up another module, then there is a problem with the orthogonality of the code. One change shouldn't impact the whole system in the first place.

Akari, are you planning to jump out of /trunk and into /branches? Or are you suggesting that everyone keep themselves tidy under /src/ffvii/(module)

/branches should be for huge application changes. (adding support for a new game for example) The problem I'm seeing with using /branches is that there is going to be huge sync issues. With a properly defined kernel API, one should be able to work within that module's directory and not break anyone's code. If Kernel functionality is needed, put it in the kernel, and make the method public. If there is a need for more module-spesific things, use the kernel APIs for the base and build from them...

I guess to make life easier, we may need to define, and write down, a good Kernal API so that work in each module doesn't confict with each other and duplicate work.

I admit, this also might be the fact the developers have a "free for all" to SVN. Most Open Source projects have the Benevolent Dictator, (In this case me), be the only person with SVN write access. Patches go through the leader and he maintains the overall workflow.

As my skills are more PR/People management/admin support, I don't have the nessasary skills to manage patches for viability. I elected to have a "hands off" approch to code management, hoping that the coders have the nessasary skills to keep from stepping on each others toes.

What's the matter with keeping everything in /trunk and each module being maintained in it's subdirectory? What kind of conflicts are coming up?
 
Hmmmm.

I don't like this idea. If you code is screwing up another module, then there is a problem with the orthogonality of the code. One change shouldn't impact the whole system in the first place.

Akari, are you planning to jump out of /trunk and into /branches? Or are you suggesting that everyone keep themselves tidy under /src/ffvii/(module)

/branches should be for huge application changes. (adding support for a new game for example) The problem I'm seeing with using /branches is that there is going to be huge sync issues. With a properly defined kernel API, one should be able to work within that module's directory and not break anyone's code. If Kernel functionality is needed, put it in the kernel, and make the method public. If there is a need for more module-spesific things, use the kernel APIs for the base and build from them...

I guess to make life easier, we may need to define, and write down, a good Kernal API so that work in each module doesn't confict with each other and duplicate work.

I admit, this also might be the fact the developers have a "free for all" to SVN. Most Open Source projects have the Benevolent Dictator, (In this case me), be the only person with SVN write access. Patches go through the leader and he maintains the overall workflow.

As my skills are more PR/People management/admin support, I don't have the nessasary skills to manage patches for viability. I elected to have a "hands off" approch to code management, hoping that the coders have the nessasary skills to keep from stepping on each others toes.

What's the matter with keeping everything in /trunk and each module being maintained in it's subdirectory? What kind of conflicts are coming up?
Click to expand...
I'm not killing other module, but I kill compilability of whole code. Sometimes there are three days of writing without code compiling.
Sometimes people will add something to code (shared between other moduls) without knowing that there are a lot more efficient way to do this. And in there updates will be usefull things and unusefull ones that are needs to be redone. In this case someone will needs copy this files to local, revert all changes, and after that do merging. It's unneeded action that could be avoided.

I knew a lot of projects where people work in there own branches and after that merge it. To tell you the truth - I myself work in local directory, and after all things are done I merge it all with trunk, so it branch after all, just local ones. And since I work on Work and Home I want posibility to upload my not working changes to SVN and get it at home.

This way we just keep writing stupid and unneeded things when everyone breaking others plans for classes.
 
I'm not killing other module, but I kill compilability of whole code. Sometimes there are three days of writing without code compiling.
Sometimes people will add something to code (shared between other moduls) without knowing that there are a lot more efficient way to do this. And in there updates will be usefull things and unusefull ones that are needs to be redone. In this case someone will needs copy this files to local, revert all changes, and after that do merging. It's unneeded action that could be avoided.

I knew a lot of projects where people work in there own branches and after that merge it. To tell you the truth - I myself work in local directory, and after all things are done I merge it all with trunk, so it branch after all, just local ones. And since I work on Work and Home I want posibility to upload my not working changes to SVN and get it at home.

This way we just keep writing stupid and unneeded things when everyone breaking others plans for classes.
Click to expand...
Having "broken" you code before, I understand what you are saying. Make it each developer's resonsability not to break /trunk.

In this case, how about creating a branch for every developer, as opposed to every module? This way every developer is responsable for fixing thier branch before a merge.

Better yet, how about when /trunk gains a release point, (from .09 to .10 for example) we then  "freeze" it to allow the other devs to fix thier implementations and merge. After all fixes are in each developer's branch is then synced and things go foreward.

... or is this what you are suggesting? If it is, then it's a good idea and I stand corrected.
 
Having "broken" you code before, I understand what you are saying. Make it each developer's resonsability not to break /trunk.

In this case, how about creating a branch for every developer, as opposed to every module? This way every developer is responsable for fixing thier branch before a merge.

Better yet, how about when /trunk gains a release point, (from .09 to .10 for example) we then  "freeze" it to allow the other devs to fix thier implementations and merge. After all fixes are in each developer's branch is then synced and things go foreward.

... or is this what you are suggesting? If it is, then it's a good idea and I stand corrected.
Click to expand...
Great! Agree with each point.
 
Ok, We can try this as an experiment.

On the next release, all developers need to fork thier code, and place a copy under /branches/devel/username under thier sourceforge username. (This makes east for me to admin, so I know who is who). This way you have the ability to revert your own branch without causing problems.

We need a time to let everyone know to start merging with trunk. I think we will need some kind of merging protocol. After the merges are complete, then we bump the release number and re-fork.

This will require a high degree of communication. Anyone have any problems with this?
 
Ok, We can try this as an experiment.

On the next release, all developers need to fork thier code, and place a copy under /branches/devel/username under thier sourceforge username. (This makes east for me to admin, so I know who is who). This way you have the ability to revert your own branch without causing problems.

We need a time to let everyone know to start merging with trunk. I think we will need some kind of merging protocol. After the merges are complete, then we bump the release number and re-fork.

This will require a high degree of communication. Anyone have any problems with this?
Click to expand...
Ok. Today I upload last merged changes for version 0.10 and add new build.
After this lets set RoadMap for next release (probably page in wiki for this?) and start work =)

Communication is good thing =)
 
I never used it yet, but TortoiseSVN has an option to merge. From what I deduced, it lets you tell the two branches you want to merge and which was the revision number they had when they got branched, then it tries to merge all changes together, and tells you of the conflicts.
I don't know if the normal SVN distribution has that feature, but if it does, then I don't see any big troubles with merging branches into trunk when needed. The only problem would be if the changes break too much the rest of the code, so the other changes need to be adapted or rewritten to work on the new base... andthat should NOT happen too often.
 
Ok, if you gyuys can manage your own branches, then that's good too.....
 
I don't know if the normal SVN distribution has that feature
Click to expand...
It does, that's the normal way of SVN branch merging.

but if it does, then I don't see any big troubles with merging branches into trunk when needed.
Click to expand...
Consider the difficulties when you have conflict with one file. Multiply it by the number of files
you may have deleted/modified in your branch, and by the number of files all the other
developers deleted/modified. If we do not merge very often into the trunk, that's what we will face.
And if we do merge often into the trunk, we don't need one branch per developper.
IMHO, using this system simply postpone each atomic problem (ie file conflict) into one
single macro-molecular problem (branch conflict).

Just know that I am not convinced of the relevancy of such a system for such a little
amount of developers; this paradigm has its benefit, when reaching hundreds of developers
working on unrelated parts of a very big project, such as the linux kernel or cairo, which rely
on another concurrent versionning system natively supporting this, namely "git".
Anyway, I will follow the final decision; if it is having one branch per user, so be it.
I am just not convinced  :wink:
 
If you put it that way... :P

But i doesn't need to be that way, I mean let me explain:
Without branching, when a dev wants to "try" something without breaking the trunk, he needs to keep the code local until it's stable enough to commit, but if the dev wants to keep the code online, and still keep the trunk clean, then branching seems the only option.

I can propose something else too: do it the other way around.
When a milestone is reached, create a branch with the "working" code of that milestone (so it can be bugfixed later and release a revised version without any experimental code in it), and keep the current code in the trunk, where the devs would continue working.
 
Status
Not open for further replies.
Back
Top