Difference between revisions of "Talk:EMU"
| Line 3: | Line 3: | ||
Do you plan to write your own repository system? I think it would be nicer if you could support already existing repositories like Subversion. | Do you plan to write your own repository system? I think it would be nicer if you could support already existing repositories like Subversion. | ||
| + | '''[[User:Barnski|Bernhard Buss]] 20:05, 21 April 2006 (GMT+1)''' | ||
We plan to make our own server, that will handle the code repository. If we were to use subversion as server we would fail our project goal: to provide more functionality than the current solutions. Although we do not know the full capacities of svn, I think it would not allow us to handle code synchronisation on a locking-base, where possibly not only whole classes are lockable, but also features. | We plan to make our own server, that will handle the code repository. If we were to use subversion as server we would fail our project goal: to provide more functionality than the current solutions. Although we do not know the full capacities of svn, I think it would not allow us to handle code synchronisation on a locking-base, where possibly not only whole classes are lockable, but also features. | ||
Nevertheless we will make sure that we design our components in a way to guarantee maximal reusability, such that the emu-client could be replaced by a svn-client for example. | Nevertheless we will make sure that we design our components in a way to guarantee maximal reusability, such that the emu-client could be replaced by a svn-client for example. | ||
Revision as of 10:11, 21 April 2006
Patrickr 18:11, 21 April 2006 (CEST)
Do you plan to write your own repository system? I think it would be nicer if you could support already existing repositories like Subversion.
Bernhard Buss 20:05, 21 April 2006 (GMT+1) We plan to make our own server, that will handle the code repository. If we were to use subversion as server we would fail our project goal: to provide more functionality than the current solutions. Although we do not know the full capacities of svn, I think it would not allow us to handle code synchronisation on a locking-base, where possibly not only whole classes are lockable, but also features. Nevertheless we will make sure that we design our components in a way to guarantee maximal reusability, such that the emu-client could be replaced by a svn-client for example.
