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

Re: Export behavior (was Re: [PATCH] svn export needs tests (issue 506))

From: John Szakmeister <john_at_szakmeister.net>
Date: 2003-11-09 20:46:43 CET

On Sunday 09 November 2003 13:23, kfogel@collab.net wrote:
> John Szakmeister <john@szakmeister.net> writes:
> > That was actually a great idea, it seems to have brought up a couple of
> > issues. Let's say I modify my working copy so that A/mu now has a
> > property set on it (svn:eol-style) and I've appended new text to it. If
> > I export the working copy, should I see the new property I set get
> > applied? I ask, because right now if I export a working copy that has
> > modified properties (but not committed), I don't see the new properties
> > applied in the export operation. The documentation for export says "All
> > local changes will be preserved, but files not under revision control
> > will not be copied." Well, technically setting a property but not
> > committing it is a local change, and I'm not seeing it get exported.
> >
> > So what's the right behavior here? Should export be applying these new
> > properties? If not, then should we update the documentation to reflect
> > this fact? If export should be applying these properties, should I open
> > an issue?
> Yeah, I think it should use the working props & text, not the base
> props & text. But I have to admit, I've never really understood the
> use cases for our "export a working copy" functionality, and so
> wouldn't consider these to be pre-1.0 bugs (just IMHO).

The strange part is that it uses the working text and the base props. If it
did was entirely one way or the other (either base text/props or working
text/props), I'd say it wasn't an issue. But the fact that it's mixed, makes
me want to treat this like a bug.

I'm not sure I understand the working copy thing either, or than you can avoid
having to touch the server again to generate a clean base from which to
package your product.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Nov 9 20:43:36 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.