> 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.
A fine goal and of course you can create a file or folder with any tool
you like. It's just not implicitly scheduled to be added.
> 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.
I hope I've misunderstood your intent here. One of the major benefits
for users moving from CVS is that Subversion does retain knowledge of
where files are copied/moved from in history. To achieve this
non-ambiguously Subversion must be involved in the copy/move
operation.
Of course sometimes you don't want the link to history but do want to
copy a folder tree - in this instance the WCA (Working Copy
Administration) does get in the way.
> 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.
For copying, the user isn't 'forced' to do so now (though they'll lose
the history link and be required to schedule additions separately).
For the deletion part of a move (or a plain deletion), you do need to
use Subversion (and you can't remove the folders until you've
committed).
For the folder copy the WCA does get in the way and that is a pain.
This is only one of several ways in which the current approach to WCA
is inconvenient - searching/replacing across folder trees being the
other biggest offender.
Note: I would not want direct deletions of files from the working copy
to be seen as implicit scheduled deletes just as I would want to see
new files implicitly scheduled for addition. These would cause more
serious issues than the current WCA layout - once committed to the
repository everyone feels the pain of a users mistake.
The good news is that it sounds like those working on the WCA layout
issue are well aware that there are issues to deal with and are
dealing with them... As noted it isn't just a trivial relabeling of
folder locations to retain all the current Subversion capability and
move the WCA at the same time.
Erik, is there a document or thread that discusses the work that is being done?
--
Talden
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Aug 29 05:53:29 2007