Can anyone explain to me how policy branches will work when they are added
to monotone one day (from a user perspective)? I ask as in the commercial
projects I'm involved in more and more files will have to be added to a
version control system. So far the projects I've been responsible for have
been using monotone. As not only source code will have to be maintained in
monotone in the future I need more fine-grained control over who may use
what. I've seen policy branches mentioned from time to time here on the
list but don't really know how they will work.
Coming from the requirements side I think I would need something like
this: I create a monotone database and make someone (like myself)
administrator. The administrator can then set read-/write-permissions for
branches. For example I could allow developers to use the branch
"sourcecode" while the documentation team will use the branch
"documentation". Once a file is checked into the branch "sourcecode" it
must remain in this branch. The settings would be stored in the database
and can not be changed by anyone except the administrator(s). If now a
developer and someone from the documentation team synchronize their
databases the developer would not get the "documentation" branch and the
other one not the "sourcecode" branch. Other branches with read/write
access for everyone would be transferred.
I don't know if policy branches in monotone will work like this and if my
idea makes actually sense (maybe there are some problems I'm not aware
of). The basic idea is that I want to continue to benefit from a
distributed version control system while I need more control over who will
get and use what. I understand that I can not prevent team members from
distributing files in another way. However I would prefer if files are not
spread to everyone automatically or accidently by the version control
system.
Boris
_______________________________________________
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel