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

RE: Reduce the 1.7 release feature set a bit?

From: Bert Huijben <bert_at_vmoo.com>
Date: Sat, 21 Aug 2010 09:26:49 -0700

> -----Original Message-----
> From: Bert Huijben [mailto:bert_at_qqmail.nl] On Behalf Of Bert Huijben
> Sent: zaterdag 21 augustus 2010 9:18
> To: 'Stefan Sperling'
> Cc: dev_at_subversion.apache.org
> Subject: RE: Reduce the 1.7 release feature set a bit?

> > > Doesn't this require the new conflict store mentioned before?
> >
> > Not necessarily. We could simply treat the presence of a .svnpatch.rej
> > file as a conflict marker.
>
> -1
> This would slow down every status walk by statting that file suffix for
> every file, because we didn't store it in the DB and getting the
information
> directly.
> (And we would have to do that in all future versions to keep compatibility
> with users removing that file to resolve the conflict)
>
> I would rather drop the entire patch support for 1.7 then going that way.
> (wc-ng-ng tomorrow?)

And what about if that file already exists?
(Normal conflicts store the location of the conflict marker to allow that
situation).

And Atomic (wq) behavior on creating the conflict marker?

We had similar issues when creating the property reject files and this
actually uses some parts of the new code to avoid these problems now. (It
uses a wq operation to write out the reject marker file).

The new conflict store would always allow recreating these markers from the
info in the db (and pristine store). Including the first time.

We should do things properly for wc-ng instead of adding new hacks that we
have to support (and possibly slows us down) indefinitely. Even if this
costs a few additional weeks before release.

>
> Bert
Received on 2010-08-21 18:28:01 CEST

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.