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

RE: Re: Proposal: svn:temporary property

From: Steve Dwire <sdwire_at_pcsigroup.com>
Date: 2003-12-18 17:47:17 CET

(Sending to list. - Man, I gotta get used to Reply-To-All)

As I understand Folker, the problem comes not at Compile time for User
B, but at UPDATE time. Because User B has compiled in the past, there
are non-versioned temporary (*.obj) files in fancy_module/subdir. This
is perfectly legitimate.

Then, User A decides that fancy_module/subdir is no longer necessary and
deletes it from his working copy and commits his changes, deleting the
same directory from the repository. This, too, is perfectly legitimate.

Finally, User B decides to UPDATE his WC. This, again, is the Right
Thing To Do. The problem is, though, that subversion is going to attempt
to delete fancy_module/subdir, but it can't because of those
non-versioned temporary files that neither Subversion nor User B knew
anything about.

This is the Problem Scenario as I understand it. User B gets a cryptic
error trying to update his WC, even neither he nor User A did anything
wrong.

Now, the part I don't understand from Folker is how the svn:temporary
attribute fixes anything. Either the temporary files are in the
repository, or they aren't. If they were in the repository, things would
work already, won't they? If they were never in the repository, how do
you propose to attach an attribute to them?

S_E_D

-----Original Message-----
From: John Peacock [mailto:jpeacock@rowman.com]
Sent: Thursday, December 18, 2003 10:07 AM
To: Folker Schamel
Cc: users@subversion.tigris.org
Subject: Re: Proposal: svn:temporary property

Folker Schamel wrote:

>> If User B had done an update before compiling, the
fancy_module/subdir
>> would have been removed from the WC and the compilation would fail
for
>> those reasons.
>
>
> No!
>
> Compilation won't fail at any time for user B.

User A deleted the directory in the repository; if user B updates
his/her WC and
the directory is deleted there too. User B also gets updated Makefile's
from
User A so that fancy_module/subdir is no longer even required for
compilation.
This is still a _user_ workflow problem.

The directory fancy_module/subdir is no longer needed for compilation
(due to
the comprehensive testing that User A did). However, User B still has
that
directory in his/her WC, so when User B compiles _without updating
first_ the
formerly active fancy_module/subdir is employed, and this blocks User B
from
updating after the fact.

> fancy_module/subdir was important part of the project for a long time.
> You cannot simply say that it should not have been added.
> Note that fancy_module/subdir contains both source files
> which are managed by svn (e.g. *.c), and temporary files which
> are not managed by svn (e.g. *.obj).

You cannot have it both ways, in that User A perceives
fancy_module/subdir is no
longer needed to compile and User B does, which is what you are
describing.
User B has an inconsistent WC with the repository modules.

>
> A svn:temporary property would solve this problem in a clean way.
>

How? Who is setting this property (and more importantly when)? What
object in
the repository is holding this property (since fancy_module/subdir is
now
deleted and Makefile's updated)? I still don't understand how a new
property
helps your use-case...

John

-- 
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD  20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Dec 18 18:39:08 2003

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.