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

RE: Re: Recurring problem with the SVN structure for WC

From: CARASSO Felipe <Felipe.CARASSO_at_gemalto.com>
Date: 2007-08-28 01:06:34 CEST

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,
        Felipe

  • application/x-pkcs7-signature attachment: smime.p7s
Received on Tue Aug 28 01:06:03 2007

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

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