Would it be seen as a good move to split the per-vcs-backends in 2,
with source methods in one class and target methods in another ?
Common methods could still be factorized in a 3rd class, which would
be the parent for the source and target ones.
I have the feeling it would make the classes more clear, and anyway we
probably never use an object in such classes at the same time as
UpdatableSourceWorkingDir and as SynchronizableTargetWorkingDir.
If we go this way, it could be a good idea to reorganize the vcpx
namespace at the same time, maybe moving those new classes to a
new vcpx.vcs namespace, maybe organized like this:
vcpx.vcs.git.core
vcpx.vcs.git.source
vcpx.vcs.git.target
Does it make sense ?
--
Yann Dirson <[EMAIL PROTECTED]> |
Debian-related: <[EMAIL PROTECTED]> | Support Debian GNU/Linux:
| Freedom, Power, Stability, Gratis
http://ydirson.free.fr/ | Check <http://www.debian.org/>
_______________________________________________
Tailor mailing list
[email protected]
http://lists.zooko.com/mailman/listinfo/tailor
