we put all changes in version control, include tools for non-
programmers.They use custom tools developed by programmers.They can
update to get latest tools when programmers made changes skip
testing ...
so they want to know what changes in those tools,but in our security
settings theny couldn't.
if programmers didn't commit in a changeset.The log message would not
make sence.
if we expose source code to others non programmer,we should need to
set separate folders access right.
maybe programmers can send custom e-mail to others to publish changes.
On 10月25日, 下午12時08分, Dale McCoy <dales..._at_gmail.com> wrote:
> > In our policy we can't let them who
> > are not programmers read souce code in version control.programmers
> > commit souce code and binary into two folders.
>
> > /src programmers read/write
> > /bin everone read/write
>
> > but if programmers commit message in a changeset,others can't read the
> > log in /bin
> > Is there anyone have the same situration? or any comments? Thanks.
>
> This raises several questions related to your choice of this usage
> pattern. I don't need the answer to any of these, but you do need to
> make sure that *you* know the answer, as your usage is significantly
> non-standard, and the standard usage is usually standard for a reason.
> 1) Why are you versioning binaries?
> 2) Why do programmers have write permissions for /bin? Isn't this why
> compile farms were invented?
> 3) Why do non-programmers have write permissions for /bin? If you
> don't have at least read access to /src, how do you create anything
> coherent to put in /bin?
>
> Questions about usage aside, I see two possible usages that fit your
> description:
> A) The programmers change the source, compile into /bin, and then
> commit the changes. In this case, you have one revision that changes
> both /src and /bin. Therefore, the change exists in both trees, and,
> by virtue of being a single revision, has a single commit message.
> Ergo, no problem: everyone can see all commit messages because all
> revisions that change /src also change /bin.
> B) The programmers change the source and commit the changes.
> Someone/something else (possibly a compile farm) checks out the
> changes, compiles into /bin, and then commits the new binaries. In
> this case, the problem is not (directly) with your use of svn, but
> with whatever updates the /bin tree. You need to reconfigure
> him/her/it to use meaningful messages when updating /bin.
>
> If neither of these are your usage pattern, or the effects I describe
> are not the effects you are actually observing, then I think you'll
> have to describe in more detail what happens between when a programmer
> makes a change to the source in their WC and when a non-programmer
> checks out the new binary and tries to figure out what changed.
>
> Dale McCoy
>
> ------------------------------------------------------http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMess...
>
> To unsubscribe from this discussion, e-mail: [users-unsubscr..._at_tortoisesvn.tigris.org].
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2675232
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2010-10-25 08:59:36 CEST