Link to home
Start Free TrialLog in
Avatar of howyue
howyueFlag for Malaysia

asked on

Comment in managing Parallel Software Development In Different Location?

There's no correct answer for my question, but i need some experts comment on this.
We are planning for a parallel development environment for 1 product(or source code) in 2 totally independent development team located in different region serving different requests.

Because the 2 teams are totally independent, they are not restricted by each other or controlled by the same management, what is the best way to periodically (yearly at most) merging the source code? Any suggestion of doing such co-operation with the minimal communiction between 2 teams?

Assumptions:
TeamA will be the one maintaining the existing code & creating new modules; TeamB in most cases will only create new modules.
The application is a N-Tier application (Client, Security, Business Logic, Access, Database) and all codes for different tier can be stored in different folder, same goes to modules.
ASKER CERTIFIED SOLUTION
Avatar of sunnycoder
sunnycoder
Flag of India image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
1)
2)
3)

see/use SVN ;-)
umm yeah ahoffman but the goals are technology agnostic ... I am not trying to sell product XYZ I am talking about things at a process level.

btw: svn doesn't offer continuous integration unless you use a tool like Cruise Control on top of it ..

That said, the important thing is continuous integration between the right branches process-wise....



Cheers,

Greg
> .. continuous integration ..
agreed, but I guess that this either needs to be implemented on top of a product XYZ, or you need something commercial which forces the sync
Avatar of howyue

ASKER

Thanks for the comments.
It a bit akward to say, actually we might plan not to use any versioning control tools between team A & B. This is because both team will hav their individual versioning control tools in their own team.
Avatar of howyue

ASKER

alternatively, i am thinking a very manual way to do it:
1. continous integration is a must, and will do it as frequent as possible.
2. with both team having their own versioning control tools, we might create a folder level control to the source seperating the development done by both team A & B. and make sure no team is modifying each other source.
3. whatever library or class is maintain by the team A, if teamB need to create their own subclass they will need ot maintain it in their own folder.

this is a very manual way, and is a less OO way.
This approach would work if you are sure that both teams would never work on the same source file.

The essence of the discussion is that you should not end up with multiple versions of the same file each containing conflicting updates. Merging such files at the end of the year (or even after one month) would be a nightmare. Since you are actively developing at different sites, conflicting changes can (and most likely will) affect functionality of the features developed by the teams. We have enough difficulty merging two different branches ... merging two trunks is unimaginable.

Even if both teams are working on different source files, it would not harm in any way to have a single source repository. You do not gain anything by having two different source repositories while advantages of having a single repository are huge.
> .. a very manual way ..
hmm, I guess every OS has a copy command, why not simply use that ;-)

Try: http://rsync.samba.org/
> .. a very manual way ..
>hmm, I guess every OS has a copy command, why not simply use that ;-)

hmm what changed? that is a very destructive method of doing things.
IMHO it's destructive to ask for a "manual way" and expecting a sophisticated-out-of-the-box-never-fails-doing-everything-right-even-that-noone-can-imagine solution. Hence I recommendet to check for rsync ;-)
BTW, copy is not destructive. Move may be destructive, or copy if it overwrites the destination.
SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Forced accept.

Computer101
EE Admin