I think the error lies with the users, not the tool. Perhaps you can
better educate those users who are having problems in the proper use
I am curious though, how they copy and paste stuff, and not get the
.svn folders. Are they doing the equivalent of moving / coping things
around without telling svn (ie, using cp and mv instead of svn cp and
svn mv) ??
If that is the case, it would be much more efficient to tell the users
the correct way to do it.
If they are using tools like TortoiseSVN, its already built in to the
On 8/27/07, CARASSO Felipe <Felipe.CARASSO@gemalto.com> wrote:
> Just for the sake of discussion (because I'm already convinced that if I want to see this done I'll have to do it myself), please
> bear with me:
> > Well, at the least, you've introduced a new error state to deal with.
> > In the current model the content folder must exist if the
> > administration area exists (one is a file-system descendant
> > of the other). In the proposed approach this is not the case
> > so you have to either treat a missing content folder as
> > missing content to be recreated during an update, evidence of
> > a remove, or a working copy error.
> Since the premisse is that only the versioned data was copied, and not the control data (note that this is the goal of my proposal),
> the assumption would be that when control is there and data isn't, it means that a "delete" needs to be commited.
> Note also that with the current model you copy versioned data *and* control data, ending up with control data that has nothing to do
> with what's in the server. This is the motivation of my proposal.
> > To maintain the 'detachability' of the current approach you
> > also need to provide a 'detach' command to extract part of an
> > existing working copy into a new, self-contained, working copy.
> Would you elaborate on that? I'm unaware of "detachability" for only part of a project tree. Is that an SVN controlled state or a
> lack of control data? In the latter, I'd think it would cause files to be reported as unversioned.
> > My point is that it is not _just_ as simple as redirecting some paths.
> Even so, I'm still inclined to think that it's way closer to the "just" than to the "changes everything in the library".
> Thank you,
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Tue Aug 28 05:04:15 2007