[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: About Takeover feature...

From: Fernandes, Filipe (Bolton) <ffernandes_at_husky.ca>
Date: 2006-09-15 19:29:28 CEST

Paul Burba wrote:
> My memory is a bit fuzzy on this, but as I recall these ideas were
> abandoned, or at least put off, because they both try to guess the user's
> intent a bit too much. In the case of "new" (i.e. unobstructing
> unversioned) files in a directory, perhaps the user *really* wants these
> to remain unversioned. Yes, I know they could revert them after the fact,
> but they could just as easily add them after the fact too. I think this
> is a case where some group of people will be unhappy no matter what the
> behavior is(?). On a related note, I am currently working on a patch that
> will allow up/sw/co to tolerate obstructions that are scheduled for
> addition without history (i.e. through svn add, not svn copy or move) -
> see http://svn.haxx.se/dev/archive-2006-09/0459.shtml. This would solve,
> or at least partially alleviate, this problem since the user can just add
> the unversioned files/dirs they want to become versioned before running
> the forced update.
>
> Re non-existing files becoming scheduled for deletion, again I think this
> tries to get in the mind of the user too much.

Ah... It's becoming clear to me. I thought I knew what was happening until I
read your two e-mails more carefully. I envisioned the feature simply
converting a folder into a working copy. What I mean by this is that the
.svn folder is populated throughout the project as follows...

1) tolerating those files that already exist

2) adding the .svn folder to those folders that already exist (effectively
versioning them and treating pre-existing files as per #1

3) creating those folders that don't exist with checked-out files from the
repository.

Could you let me know if this is 'far' from the truth...? I guess I should
have involved myself with the mailing list much earlier than this. :(

filipe

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Sep 15 19:28:53 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.