About Takeover feature...

["Fernandes, Filipe (Bolton)" <ff...@husky.ca>]

Just a question... last I heard about the takeover feature was in August and
that they're might have been some future debate on its use (ie. command line
switches).  I haven't been following this too closely but definitely would
find this to be of great use.

 

Do you know what feature release it might be deployed in (1.5 or 2.0?)

 

filipe

 

Ps: Sorry if this should have been asked in the users list.... 

 

Re: About Takeover feature...

[Molle Bestefich <mo...@gmail.com>]

Fernandes, Filipe (Bolton) wrote:
> Just a question... last I heard about the takeover feature was in August and
> that they're might have been some future debate on its use (ie. command line
> switches).  I haven't been following this too closely but definitely would
> find this to be of great use.

It's not called takeover anymore.  It's called "checkout --force",
because that's what it does - a forced checkout.  New files from your
local folder is not taken over.  (Neither will local deletes be
honoured as SVN operations.)

I'm unsure what happens with existing local files that are different
to those in the repository - supposedly they'll be overwritten with
versions from the repository?  Or maybe treated as changes?  There's a
duality of "--force" here - it could mean both.

The only reason you're still seeing "takeover" on the mailing list is
because the original author keeps posting messages with that (wrong)
name in the subject.

> Do you know what feature release it might be deployed in (1.5 or 2.0?)

Seems like the feature is about ready to go, so should be in 1.5 I reckon?

I hope someone feels like implementing an actual takeover (not forced
checkout) feature too at some point.  Would be very useful!

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: About Takeover feature...

[Jared Hardy <ja...@gmail.com>]

On 9/15/06, Paul Burba <pa...@softlanding.com> wrote:
> "Giovanni Bajo" <ra...@develer.com> wrote on 09/15/2006 11:07:22 AM:
>
> > Paul Burba wrote:
> >
> > > The code was committed to trunk in early August.  It's not called
> > > takeover anymore - you can dig through the threads on "takeover" if
> > > you are curious about the gory details as to why
> > > http://svn.haxx.se/dev/...

I know I'm late into this discussion, but I'm wondering if the new
"--force" functionality for  up, co, and sw (especially up) can be
found in any stable branch, or any branch other than trunk. This is
one feature I've been dreaming of since hitting my first
"unversioned... exists, failed update" type error, and I want it ASAP!
I've written wrapper tools to do pretty much the same thing, as well
as work-around Windows file lock issues, but I'm sure the core code
does it much better than my script.

> Re non-existing files becoming scheduled for deletion, again I think this
> tries to get in the mind of the user too much.

I must agree on this point!  In our case, we version a lot of
built-data (like .exe, but for art) and in-between data (like .o
files, but again for art), and we have a lot of debug, text, and log
data in the same directories that we don't feel the need to version,
but like to keep around for reference. When two people build the same
source at the same time, and attempt to commit at different rates, the
last to commit "loser" often gets stuck with a mess of update errors
and cleanups to run through. Deleting the log and reference files
would be less of a penalty than the current situation, but perceived
as a penalty nonetheless. I agree with the usual Subversion rule of
"don't destroy local data unless specifically instructed, via delete,
revert, etc". I view this form of previously-unversioned match version
tagging as completely non-destructive.
    In cases where the user wants to delete unversioned files after an
up/co/sw --force, it should be a lot easier to script it afterwards by
parsing the recursive status output data. Certainly that would be much
easier than trying to recover any lost data, caused by an accidental
mis-use of destructive commands on non-versioned files.

> Please take all this for what it is: my opinion!  If someone can
> demonstrate a real need for further enhancements co/sw/up --force, can
> clearly articulate the desired behavior, and can get some agreement from
> the community that it's a "good thing" then it can happen.

I think the behavior already described in this thread matches our
use-case exactly -- better than the current default Subversion
behavior. The need for a SVN_ERR_WC_OBSTRUCTED_UPDATE never made any
sense to me at all. In fact, I don't quite see why using a flag like
"--force" should be necessary to attain this behavior at all! Why
can't this be the default up/co/sw behavior?

    Thanks,
    Jared

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: About Takeover feature...

[Giovanni Bajo <ra...@develer.com>]

Paul Burba wrote:

> My memory is a bit fuzzy on this, but as I recall these ideas were
> abandoned, or at least put off, because they both try to guess the
> user's intent a bit too much.  In the case of "new" (i.e.
> unobstructing unversioned) files in a directory, perhaps the user
> *really* wants these to remain unversioned.  Yes, I know they could
> revert them after the fact, but they could just as easily add them
> after the fact too.  I think this is a case where some group of
> people will be unhappy no matter what the behavior is(?).

Exactly. This is why the behaviour should be discussed exclusively on the
basis of real-world use-cases (as it is always done for Subversion
features), and not on the basis of what "is supposed" to be better. I cannot
find the design document for the takeover version that was eventually
committed, so I cannot see what the rationale is for either choice.

If you decide *not* to schedule-add/remove files in obstructed directory,
you obtain a working copy which very close to what would happen if you first
checkout, and then copy your directory over the working copy. In other
words, what Subersion is doing is just saving the "copy-over" pass, which is
better than nothing but really not a great deal. On the other hand, adding /
removing files in obstructed directory is *very* tedious and annyoing. It
basically requires some shell scripting to be done in a complex tree, and
for instance you simply cannot do it in an automatic fashion under Windows.

>> If this was the case, "svn checkout --force" would
>> automatically do much of the job of svn_load_dirs.pl, and thus would
>> be dramatically useful for vendor branches.
>
> Sorry, I'm not familiar with svn_load_dirs.pl so I'll have to let
> someone else speak to that.

svn_load_dirs.pl was born exactly for this specific scenario (vendor
branches). If you committed foo 1.0 to your repository and you get
foo-1.1.tar.gz, you want to commit it into the repository "as if" it was a
single patch (that brings 1.0 to 1.1). To do it manually, you need to
checkout the 1.0 version, unpack the tar.gz over it, and then add/remove all
files manually. svn_load_dirs automates this process, and also tries to
detect renamed files, do the commit, ecc.

This is why I would like "svn co --force" to behave like this. It would be a
great support for vendor branches, which is widely common use cases (and
even if it's irrelevant, let me note that CVS supports vendor branches much
better than SVN does, since for instance it takes care of this
automatically).

I'm curious about whether there are use cases in which adding/removing files
in obstructed directories is worse than doing nothing with them, because I
cannot think of them right now. I guess that, if they exist, they are in the
design document (which I cannot find). Otherwise, if this specific aspect
was never discussed before in this context, my +1 is towards
auto-schedule-add/delete in obstructed directory.
-- 
Giovanni Bajo

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: About Takeover feature...

[Paul Burba <pa...@softlanding.com>]

"Giovanni Bajo" <ra...@develer.com> wrote on 09/15/2006 11:07:22 AM:

> Paul Burba wrote:
> 
> > The code was committed to trunk in early August.  It's not called
> > takeover anymore - you can dig through the threads on "takeover" if
> > you are curious about the gory details as to why
> > http://svn.haxx.se/dev/...
> 
> I tried, but the threads are pretty long and it's not immediately clear 
what
> is the final "result" of the discussions.

Heh, I called the details "gory" for a reason :-)

> I'll try ask my question anyway.
> 
> Was it considered to treat new files in an obstructed directory as
> "scheduled add", and non-existing files in an obstructed directory as
> "scheduled delete"?

Hi Giovanni,

My memory is a bit fuzzy on this, but as I recall these ideas were 
abandoned, or at least put off, because they both try to guess the user's 
intent a bit too much.  In the case of "new" (i.e. unobstructing 
unversioned) files in a directory, perhaps the user *really* wants these 
to remain unversioned.  Yes, I know they could revert them after the fact, 
but they could just as easily add them after the fact too.  I think this 
is a case where some group of people will be unhappy no matter what the 
behavior is(?).  On a related note, I am currently working on a patch that 
will allow up/sw/co to tolerate obstructions that are scheduled for 
addition without history (i.e. through svn add, not svn copy or move) - 
see http://svn.haxx.se/dev/archive-2006-09/0459.shtml.  This would solve, 
or at least partially alleviate, this problem since the user can just add 
the unversioned files/dirs they want to become versioned before running 
the forced update.

Re non-existing files becoming scheduled for deletion, again I think this 
tries to get in the mind of the user too much.

Please take all this for what it is: my opinion!  If someone can 
demonstrate a real need for further enhancements co/sw/up --force, can 
clearly articulate the desired behavior, and can get some agreement from 
the community that it's a "good thing" then it can happen. 

> If this was the case, "svn checkout --force" would
> automatically do much of the job of svn_load_dirs.pl, and thus would be
> dramatically useful for vendor branches.

Sorry, I'm not familiar with svn_load_dirs.pl so I'll have to let someone 
else speak to that.

Paul B.

> Giovanni Bajo

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: About Takeover feature...

[Giovanni Bajo <ra...@develer.com>]

Paul Burba wrote:

> The code was committed to trunk in early August.  It's not called
> takeover anymore - you can dig through the threads on "takeover" if
> you are curious about the gory details as to why
> http://svn.haxx.se/dev/...

I tried, but the threads are pretty long and it's not immediately clear what
is the final "result" of the discussions. I'll try ask my question anyway.

Was it considered to treat new files in an obstructed directory as
"scheduled add", and non-existing files in an obstructed directory as
"scheduled delete"? If this was the case, "svn checkout --force" would
automatically do much of the job of svn_load_dirs.pl, and thus would be
dramatically useful for vendor branches.
-- 
Giovanni Bajo

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: About Takeover feature...

[Paul Burba <pa...@softlanding.com>]

"Fernandes, Filipe (Bolton)" <ff...@husky.ca> wrote on 09/15/2006 
09:29:48 AM:

> Just a question... last I heard about the takeover feature was in 
> August and that they're might have been some future debate on its 
> use (ie. command line switches).  I haven't been following this too 
> closely but definitely would find this to be of great use.

Hello Filipe,

The code was committed to trunk in early August.  It's not called takeover 
anymore - you can dig through the threads on "takeover" if you are curious 
about the gory details as to why http://svn.haxx.se/dev/... 

...But at the moment the 'functionality-previously-known-as-takeover' is 
implemented with the --force option for svn checkout, update, and switch. 
Previously --force was unused for these three subcommands.  Please note 
that by the time 1.5 arrives this functionality may be tied to another 
option as there is still some debate about using --force.

Also, different people had differing expectations of what "takeover" would 
do, what eventually made it into the code is the following: 

[[[
Support --force option with svn checkout, update, and switch.

With the force option, co, sw, and up now tolerate unversioned
obstructing paths when adding new paths of the same type, rather than
generating a SVN_ERR_WC_OBSTRUCTED_UPDATE error.

If the obstructing path is the same type (file or directory) as the
corresponding path in the repository it will be left 'as-is' in the
working copy.  For directories this simply means the obstruction is
tolerated.  For files, any content differences between the obstruction
and the repository are treated like a local modification to the
working copy.

This patch is an expansion of one originally posted by Jonathan Gilbert
<o2...@sneakemail.com> against the 1.2.0 tag.  See the various
"Takeover" threads on the dev mailing list.
]]]

If that isn't clear let me know and I can clarify further. 
 
> Do you know what feature release it might be deployed in (1.5 or 2.0?)

1.5 is the plan, but before you ask, I don't know when that will be :-)

Hope that helps,
 
Paul B.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org