"Michael H. Pryor" <firstname.lastname@example.org> wrote on 08/17/2004 04:47:44 PM:
> Sounds great. I think if the SVN team doesn't want to deal with this or
> document it, then we should just go with what we think is best and
> it ourselves. Then if other GUI's want in on the action, they can
> our lead. Clearly, it would be ideal to have the spec implemented in
> core so others could use it too, but I think we have a decent
> of the problem and if they don't want to, or don't have the cycles to,
> implement this feature set, then that's ok. The integration (bug
> tracker->svn) already exists using an SNV hook, I just want to make it
> robust by extending it through TortoiseSVN so we can go back the other
> (svn->bug tracker).
This is what I think svn could do:
1) Elevate bug ID to a full-fledged citizen, like the log message. A lot
of the validation and configuration for that could then be part of
Subversion. This seems unlikely they will do. Compromise seemed to be to
allow revprops to be part of the commit. That was the Bug ID I
2) Configuration. Perhaps do something to help us with the config
options. The main thing would be to define config in repository and have
that pushed to client. Then we could just piggy-back on that. I do not
know how likely that is.
I wonder if revprops on rev 0 could somehow be stored in the WC? Perhaps
that would be how they would do it?
Otherwise, I think all that svn could really do would be to publicize the
"conventions" we adopt and encourage other GUI clients to do the same.
Maybe we just need Joel to write an article on this :)
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Wed Aug 18 08:52:31 2004