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

Re: can of worms: custom props in our tree?

From: John Peacock <jpeacock_at_rowman.com>
Date: 2003-11-07 13:39:26 CET

Greg Noel wrote:
> Have I got it? If so, then this seems perfectly reasonable.

He's got it! By george I think he's got it! ;~)

<with apologies to G.B. Shaw and A.J. Lerner>

> Correct me if I'm wrong, but isn't tracking mergepoints like this
> intended to be part of the basic SVN processing? If not now, then
> someday? And if that's the case, shouldn't there be some concern about
> how this will impact that functionality?

No impact at all, since the proposed attribute isn't in the official svn:
address space (it is a user attribute). It does make for a good way to test the
procedure, however. This model is, AFAIK, exactly how CVSNT is handling

> And then there's the scenario where the user doesn't create a branch,
> but applies his changes directly to the (local) trunk, merging from time
> to time from the public repository. What happens when he pushes that
> changeset? (This is how I was thinking it would be done; work on
> changes locally, commit them locally as needed to keep track of what
> you're doing, then ship the finished modifications as a single
> transaction.)

The proposed code doesn't help this person at all, unless she is using svk, in
which case it is a completely different client/model. Eventually, having
mergepoint support in the WC will be required to support this mode of operation,
but that isn't the current discussion.


John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4720 Boston Way
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Nov 7 13:39:42 2003

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.