RE: Recurring problem with the SVN structure for WC

> -----Original Message-----
> From: Talden [mailto:talden@gmail.com]
> Sent: Tuesday, August 28, 2007 4:00 AM
> To: Ryan Schmidt
> Cc: Matt Sickler; CARASSO Felipe; users@subversion.tigris.org
> Subject: Re: Recurring problem with the SVN structure for WC
>
> > Subversion is not a toaster. It's a complicated piece of machinery,
> > and only proper education of the users will result in its
> being used
> > correctly.
>
> Absolutely. Users still need to understand the implications
> of their actions.

        Before replying, a reminder: I'm advocating for what I think that would make Subversion a better product. My thoughts come
from the need of making Subversion useful to people other than developers and system administrators. Many of these people are
qualifiers and project managers.

        I find it a dangerous perspective to use "RTFM" as a default answer, specially when a product is fighting its way into
widespread acceptance.

        First of all, the task of controlling the version of a project should not have more priority than other tasks that are only
related to the development of that project.

        Starting from there, the development should only depend on whatever tool the developer finds fit. Let's say that for
creating a file or a folder the developer likes to use, say, TotalCommander. Creating a file or folder likely includes copying that
file or folder from somewhere else in the project.

        Just then, the developer should be able to decide that his project is in a state that requires versioning. Just then, it
should call Subversion and ask for versioning-related operations.

        I believe that copying files and folders around in a project should not be considered part of Subversion's group of
operations. That's why I have the impression that "svn copy" and "svn move" are more like workarounds to support what has been
decided as "how Subversion works" rather than being part of version control tasks.

        So if I'm right, and if my proposal is feasible, I don't see why the user should be forced to do copy/move under a
Subversion-controlled environment if he could use whatever tool he'd like without compromising the version control.

>
> In the suggested solution, users who use an OS delete of
> folders in the working copy would implicitly have scheduled
> removals. A commit from an unaware user could be disastrous
> (of course the same disaster is currently possible by
> touching files and committing those - explicit scheduling of
> changes would avoid this).

        I'm not sure, but it looks like you replied to your own statement there :) If I'm not mistaken, in the current Subversion
context, implicit changes can happen no matter how the user does changes to the project. It all depends on how you define
"implicit". For me, if the user does 100 changes and forgets about 80, those 80 become implicit.

Best regards,
        Felipe