Hi Greg--
Thanks for the feedback.
> > Umm... I understand *how* Subversion works. The problem is trying to
> > make Subversion checkouts work with an already well-established model
> > for the interaction of build tools and (other) source code management
> > system.
>
> I tend to believe that this model is rarely used (contrary to your
> initial assertion) and fundamentally flawed.
It may be rarely used in your circles, but there are definitely people
and development shops that still use this model extensively.
FWIW, I have direct experience with real, live users requesting exactly
this feature (for SCCS and RCS, and by extension, BitKeeper) on two
related build tools that I've worked on. Either there are more people
using this model than you believe, or I just got lucky and happened to
hit representatives of a very small population.
I'm not saying this way of working is flawless, just pointing out that
(some? a lot of?) real software developers still find it useful enough
to use it successfully. So in order to serve my user community, I need
to support this model, and I thought I'd like to extend that support to
Subversion. I'm beginning to believe that it just doesn't make sense
for Subversion, though...
> If the build tool checks out individual files at a time, developers will
> lose the advantage of atomic commits. Consider what happens if I do a
> build at the same time as someone else does a commit:
>
> Build: "I need foo.c, so I check it out at the current rev."
> <commit finishes, modifying foo.c and bar.c>
> Build: "I need bar.c, so I check it out at the current rev."
>
> Now I have foo.c and bar.c from two different revisions, which
> potentially aren't consistent with each other.
Once again: I'm not trying to change Subversion's model. I'm trying
to come up with a creative way to make that model work in some way that
fits some established software development practices for other tools.
Maybe that just doesn't exist.
Thanks again for taking the time to reply.
--SK
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Mar 25 02:16:18 2003