You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Paul Burba <pa...@softlanding.com> on 2006/04/14 14:58:26 UTC
[PROPOSAL] Takeover Take 2 Was: Re: the 'takeover' feature
Paul Burba <pa...@softlanding.com> wrote on 04/11/2006 04:16:02 PM:
> Hi All,
>
> Just wondering what ever became of takeover...does it still have any
life?
> As Mark has mentioned a few times in the thread, this would be very
> helpful re Subclipse.
>
> I'm glad to attempt any grunt work required to get Jonathan's old 1.2
> patch caught up to trunk if that's all that's holding this up.
>
> Please let me know, thanks,
>
> Paul B.
>
> kfogel@newton.ch.collab.net wrote on 09/16/2005 06:20:36 PM:
>
> > Greg Hudson <gh...@MIT.EDU> writes:
> > > Well, I'm not part of this consensus.
> > >
> > > I think checkout should tolerate existing directories by default. No
> > > need for a flag for that. That should alleviate that Eclipse use
> case.
> >
> > Yes -- in fact, I thought this was the conclusion we came to earlier
> > (though the thread has been long, and I don't blame anyone for
> > forgetting a later conclusion and backtracking to an earlier one).
> >
> > +1 on checkout just Doing The Right Thing when invoked over an
> > existing local tree, by default. No need for a new switch here.
> >
> > -Karl
I didn't hear from anyone so I'd like to push this forward.
Pouring over the takeover threads there seems to be a consensus that
checkout is the place for this functionality and that further
optimizations/improvements can wait. There is less agreement on the
question of whether co needs a new option --takeover, should use --force,
or should just behave this way by default (my vote if for the last
option). I'm going to start work shortly on a patch to trunk based on
Jonathan's 1.2.0 patch. If anyone out there has strong objections or
something to add please let me know.
Thanks,
Paul B.
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PROPOSAL] Takeover Take 2 Was: Re: the 'takeover' feature
Posted by Daniel Rall <dl...@collab.net>.
On Fri, 14 Apr 2006, Peter N. Lundblad wrote:
> Paul Burba writes:
> > Paul Burba <pa...@softlanding.com> wrote on 04/11/2006 04:16:02 PM:
> >
> > I didn't hear from anyone so I'd like to push this forward.
> >
> > Pouring over the takeover threads there seems to be a consensus that
> > checkout is the place for this functionality and that further
> > optimizations/improvements can wait. There is less agreement on the
> > question of whether co needs a new option --takeover, should use --force,
> > or should just behave this way by default (my vote if for the last
> > option). I'm going to start work shortly on a patch to trunk based on
> > Jonathan's 1.2.0 patch. If anyone out there has strong objections or
> > something to add please let me know.
> >
>
> I like this idea.
+1
--
Daniel Rall
Re: [PROPOSAL] Takeover Take 2 Was: Re: the 'takeover' feature
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
Paul Burba writes:
> Paul Burba <pa...@softlanding.com> wrote on 04/11/2006 04:16:02 PM:
>
> I didn't hear from anyone so I'd like to push this forward.
>
> Pouring over the takeover threads there seems to be a consensus that
> checkout is the place for this functionality and that further
> optimizations/improvements can wait. There is less agreement on the
> question of whether co needs a new option --takeover, should use --force,
> or should just behave this way by default (my vote if for the last
> option). I'm going to start work shortly on a patch to trunk based on
> Jonathan's 1.2.0 patch. If anyone out there has strong objections or
> something to add please let me know.
>
I like this idea.
Regards,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PROPOSAL] Takeover Take 2 Was: Re: the 'takeover' feature
Posted by Alan Barrett <ap...@cequrux.com>.
On Fri, 14 Apr 2006, John Peacock wrote:
> Just to confuse the matter, I'm still of the opinion that checkout
> should not silently absorb a pre-existing directory tree.
I very much want the ability to convert a pre-existing non-WC tree into
the equivalent of a WC tree with local changes. I think that it should
not be the default, because it's too different from a normal checkout.
I would like the result to be equivalent to what I currently get from
this sequence of commands:
cd /path/to/existing/tree
svn checkout url://to/repo/path ./tmpdir
( cd tmpdir ; find . -name .svn -type d -print ) \
| while read subdir ; do
if [ -d "${subdir}" ] ; then
mv "tmpdir/${subdir}/.svn" "${subdir}/.svn"
fi
done
rm -rf tmpdir
In other words, .svn directories get created and populated with
metadata, but files outside the .svn directories are not created,
deleted, or modified in any way, and non-.svn directories are neither
created nor deleted.
> 1) a file on disk is executable, but in the repository isn't tagged as
> svn:executable, what happens?
The file on disk remains as it was before. "svn status" reports the same
as if you had done a checkout into an empty directory, and then "chmod
+x filename".
> 2) the reverse of 1 (svn:executable is set but the existing file
> isn't)?
The file on disk remains as it was before. "svn status" reports the same
as if you had done a checkout into an empty directory, and then "chmod
-x filename".
> 3) svn:ignores filters file out of the absorbed tree (this is probably
> harmless since the file could be manually added when the ? status was
> noticed)?
The files on disk remain as they were before. "svn status" reports the
same as if you had done a checkout into an empty directory, and then
created some new files.
--apb (Alan Barrett)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Takeover Take 2 Was: Re: the 'takeover' feature
Posted by Jonathan Gilbert <o2...@sneakemail.com>.
At 12:58 PM 21/04/2006 -0400, Paul Burba wrote:
>"Jonathan Gilbert" wrote on 04/21/2006 12:23:15 PM:
>
>> svn checkout --force
>> Should blindly overwrite existing local files. A user using this
>option
>> should be well aware of this behaviour and not use it if he is worried
>> about losing local changes.
>
>Hi Jonathan,
>
>Respectfully, I strongly disagree with this idea. A user's local files
>might be the only copy they have. For Subversion to overwrite these
>files, even if only when using --force, seems too harsh and doesn't
>actually solve a problem anyone has(?).
>
>I don't spend a lot of time reading the users list, but I suspect there
>are a host of new users out there who could easily shoot themselves in the
>foot with something like this. We can't save people from driving off the
>cliff all the time, but we can at least throw up some guardrails. No?
My point was more that I strongly disagree with "--force" being used for
"the functionality formerly known as takeover". It really doesn't say what
it's doing *at all*. What I meant to say, but didn't really make clear, was
that that is how I think "checkout --force" should behave *if it is given
that flag at all*.
Sorry I wasn't clear :-)
Jonathan Gilbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Takeover Take 2 Was: Re: the 'takeover' feature
Posted by Michael Sweet <mi...@easysw.com>.
Jonathan Gilbert wrote:
> At 01:33 PM 21/04/2006 -0400, you wrote:
>> Jonathan Gilbert wrote:
>>> ...
>>>> equivalent of a checkout in that directory, e.g.:
>>>>
>>>> svn import --takeover http://foo.bar.com/myproject/trunk
>>>>
>>>> to import the current directory or:
>>>>
>>>> svn import --takeover myproject http://foo.bar.com/myproject/trunk
>>>>
>>>> to import the named directory and setup a WC there.
>>> This is completely the opposite of the original reason I designed the
> feature.
>>> ...
>> OK, I've read your post, and I don't understand why this would be
>> "completely the opposite". My suggestion for an import option would
>> be equivalent to doing a checkout with option or a new takeover
>> command after the import.
>>
>> In short, why not provide an option to import that is a shortcut for
>> a (relatively) common use case?
>
> As I said before, "svn import"'s main function is to add files to the
> repository when the local copy is not a WC. The function of "svn takeover"
> is to turn something that is ostensibly a working copy, just not one that
> Subversion knows about, into an official SVN working copy without sending
> anything to the server. In fact, the latest revision is *retrieved* from
> the server, in order to build the text-base.
>
> Are you suggesting that "svn import --takeover" would *not* commit a new
> revision to the repository?
It could be implemented in one of two ways:
1. Import (commit) as it does currently, and then takeover the
imported directories as a WC.
2. Create a WC with scheduled adds for all of the files and
directories.
I'm thinking that #1 is trivial to implement using the (new) existing
checkout/takeover code, while #2 would be a much bigger effort.
> Are you talking about a separate feature here that would automate the
> process of "URL=svn://... (svn import $URL && svn takeover $URL)"?
Yes, exactly. Whether Subversion adds an option to import that
does the takeover is up to you guys, but it seems to me that a) this
is probably a pretty common use case, and b) it should be trivial
to add using the new APIs for the takeover stuff anyways.
Of course, if you don't add an option to import, I'll just write
another short script ("svnimport.sh") that combines the two commands
like I do for common merge and branch stuff...
--
______________________________________________________________________
Michael Sweet, Easy Software Products mike at easysw dot com
Internet Printing and Publishing Software http://www.easysw.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Takeover Take 2 Was: Re: the 'takeover' feature
Posted by Jonathan Gilbert <o2...@sneakemail.com>.
At 01:33 PM 21/04/2006 -0400, you wrote:
>Jonathan Gilbert wrote:
>> ...
>>> equivalent of a checkout in that directory, e.g.:
>>>
>>> svn import --takeover http://foo.bar.com/myproject/trunk
>>>
>>> to import the current directory or:
>>>
>>> svn import --takeover myproject http://foo.bar.com/myproject/trunk
>>>
>>> to import the named directory and setup a WC there.
>>
>> This is completely the opposite of the original reason I designed the
feature.
> > ...
>
>OK, I've read your post, and I don't understand why this would be
>"completely the opposite". My suggestion for an import option would
>be equivalent to doing a checkout with option or a new takeover
>command after the import.
>
>In short, why not provide an option to import that is a shortcut for
>a (relatively) common use case?
As I said before, "svn import"'s main function is to add files to the
repository when the local copy is not a WC. The function of "svn takeover"
is to turn something that is ostensibly a working copy, just not one that
Subversion knows about, into an official SVN working copy without sending
anything to the server. In fact, the latest revision is *retrieved* from
the server, in order to build the text-base.
Are you suggesting that "svn import --takeover" would *not* commit a new
revision to the repository?
Are you talking about a separate feature here that would automate the
process of "URL=svn://... (svn import $URL && svn takeover $URL)"?
If it is the latter, then I apologize, because I (mis)read your original
post as suggesting an alternate place for the takeover feature, to the
exclusion of it having its own command (or flag to "checkout" or what have
you).
Jonathan Gilbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Takeover Take 2 Was: Re: the 'takeover' feature
Posted by Michael Sweet <mi...@easysw.com>.
Jonathan Gilbert wrote:
> ...
>> equivalent of a checkout in that directory, e.g.:
>>
>> svn import --takeover http://foo.bar.com/myproject/trunk
>>
>> to import the current directory or:
>>
>> svn import --takeover myproject http://foo.bar.com/myproject/trunk
>>
>> to import the named directory and setup a WC there.
>
> This is completely the opposite of the original reason I designed the feature.
> ...
OK, I've read your post, and I don't understand why this would be
"completely the opposite". My suggestion for an import option would
be equivalent to doing a checkout with option or a new takeover
command after the import.
In short, why not provide an option to import that is a shortcut for
a (relatively) common use case?
--
______________________________________________________________________
Michael Sweet, Easy Software Products mike at easysw dot com
Internet Printing and Publishing Software http://www.easysw.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Takeover Take 2 Was: Re: the 'takeover' feature
Posted by Julian Foad <ju...@btopenworld.com>.
Molle Bestefich wrote:
> Mark Phippard wrote:
>
>>We just need a way to do it. Paul is going in the direction
>>he is because that is what the committers indicated they
>>wanted back when this first came up.
>
> That's great.
>
> For reasons already mentioned, I'd like the takeover functionality to
> only slide metadata into the directory structure. If one needs files
> checked out too it can be done with 'svn update' afterwards.
>
> I'd like to propose that the command be named either:
[...]
> Any commiters willing to comment?
Yes, but I'm not going to discuss the naming until we're absolutely clear about
what we want the command to do.
It's clear that enough people want to be able to do this sort of thing -
connect an existing local copy to a repository. It's time we had a written
design proposal to consider.
We should look at the big picture: see how this operation fits into the set of
things that Subversion does, and design a solution that is capable of
addressing the "import + checkout in place" scenario as well as the "connect
this local non-WC tree to its repository" scenario.
* Create a local copy from a repository project:
repos-proj -> repos-proj + local-proj
(disconnected)
Existing solution: "svn export"
repos-proj -> repos-proj + local-proj-WC
(connected)
Existing solution: "svn checkout"
* Create a repository project from a local copy:
local-proj -> repos-proj + local-proj
(disconnected)
Existing solution: "svn import"
local-proj -> repos-proj + local-proj-WC
(connected)
Solution wanted. Suggest fundamentally a two-step method, "svn import" +
something like "svn takeover" (command name and syntax to be decided), though a
single-step UI would be convenient in addition. In this method, the "takeover"
step doesn't have to deal with any added/modified/deleted files (as long as it
fetches the same revision that the "import" step created).
* Connect a local project to a repository project, making it into a WC:
repos-proj + local-proj -> repos-proj + local-proj-WC
(disconnected) (connected)
Solution wanted. Suggest this be the fundamental "takeover" operation.
Details about mis-matching files to be discussed below.
* Permanently disconnect a WC from its repos (like exporting in place):
repos-proj + WC -> repos-proj + local-proj
(connected) (disconnected)
Explicit support for this operation might be a good idea in the end, but
need not be addressed now - it's probably uncommon enough that the work-around
(deleting the ".svn" directories") is acceptable. It's worth considering
whether such a command might be a direct counterpart to the one that connects a
local copy to a repository (e.g. "svn connect" and "svn disconnect").
ADDED/MODIFIED/DELETED FILES
Briefly, since we'd clearly expect the newly connected WC to have local file
differences reported by "svn status" as "locally Modified" (rather than
"unknown" or "broken"), it is logical to have missing files reported as
"Deleted" and extra files as "Added".
Should the local files' properties be as "import" or "add" would have set them,
and any differences from the repos marked as "Modifications", or do we need a
way to say "Get all props from the repos"?
Are there any other edge cases to consider?
It would be great if someone could write up a draft proposal with the complete
syntax (picking a particular command name to make it a concrete proposal),
semantics (especially the difficult stuff about mis-matching files/properties),
and simple examples of its use in each of the two main scenarios ("import" and
"connect").
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Takeover Take 2 Was: Re: the 'takeover' feature
Posted by Molle Bestefich <mo...@gmail.com>.
Mark Phippard wrote:
> We just need a way to do it. Paul is going in the direction
> he is because that is what the committers indicated they
> wanted back when this first came up.
That's great.
For reasons already mentioned, I'd like the takeover functionality to
only slide metadata into the directory structure. If one needs files
checked out too it can be done with 'svn update' afterwards.
I'd like to propose that the command be named either:
svn integrate
Or:
svn checkout --metadata-only
This name is less good:
svn checkout --takeover
Because it seems like "takeover" is prone to get confused with a
feature that does 'svn import' of a directory and then slides metadata
into that directory.
Any commiters willing to comment?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Takeover Take 2 Was: Re: the 'takeover' feature
Posted by Mark Phippard <ma...@softlanding.com>.
"Molle Bestefich" <mo...@gmail.com> wrote on 04/21/2006 11:25:01
PM:
> While I completely understand that Subclipse need to have files
> checked out on top, I think that that's a case which can easily be
> handled by Subclipse doing an 'svn update' to the right revision after
> converting to a WC.
>
> The great many other feats that can be accomplished with this feature
> shouldn't have to be abolished by integrating these two actions just
> because it happens to be slightly more practical for Subclipse, me
> thinks.
I just wanted to point out that this feature is not specifically about
Subclipse, that just happens to be why I would like to see it. Jonathan
Gilbert wrote the initial patch which generated the conversations that
have led to where this is today. None of that had anything to do with
Subclipse. My only involvement was making a resource (Paul Burba)
available to revive the patch and see if it can be made to work. And yes,
I want it because it will let me fix some things in Subclipse that people
have asked for. But all Subclipse needs is the raw capability. It does
not matter to us whether it is a --force switch, or a new command, or two
new commands. We just need a way to do it. Paul is going in the
direction he is because that is what the committers indicated they wanted
back when this first came up.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Takeover Take 2 Was: Re: the 'takeover' feature
Posted by Molle Bestefich <mo...@gmail.com>.
Jonathan Gilbert wrote:
> [ snip ]
I completely agree with _almost_ all of your points and reasoning.
> For me, the fact that "update" would add missing files automatically
> as part of my "takeover" operation was never a problem,
> because I never actually *had* other files to be checked out that weren't
> already in the local copy.
It did *not* provide any value for you, though, and there's a real
chance that converting to a real WC and then checking out a bunch of
files on top at the same time will leave a lot of people really
confused.
While I completely understand that Subclipse need to have files
checked out on top, I think that that's a case which can easily be
handled by Subclipse doing an 'svn update' to the right revision after
converting to a WC.
The great many other feats that can be accomplished with this feature
shouldn't have to be abolished by integrating these two actions just
because it happens to be slightly more practical for Subclipse, me
thinks.
Have I mentioned already that I also find it cleaner if separate? I
might have :-)..
> As I see it, though, such files should be automatically scheduled
> for deletion in the repository; otherwise, the working copy is
> inconsistent with the "entries" file and gets tagged, as
> mentioned by a previous poster, with a '!' in "svn status".
Automatically scheduling files for deletion would actually be a gift
for my backup purposes :-), but I think it's the wrong thing to do
anyway. I do not find "missing" status inconsistent at all.
You tell Subversion to pretend that a folder is a WC, and Subversion
tells you that in that case some files have gone missing from that WC
and it's not quite sure if it's intentional. With a real WC you would
have explicitly told Subversion to remove each file from versioning
with 'svn rm', and I think that should apply here too.
(What I *would* like to see is a '--remove-missing' option to 'svn
commit' though...)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Takeover Take 2 Was: Re: the 'takeover' feature
Posted by Paul Burba <pa...@softlanding.com>.
"Jonathan Gilbert" <o2...@sneakemail.com> wrote on 04/21/2006 12:23:15
PM:
> svn checkout --force
> Should blindly overwrite existing local files. A user using this
option
> should be well aware of this behaviour and not use it if he is worried
> about losing local changes.
Hi Jonathan,
Respectfully, I strongly disagree with this idea. A user's local files
might be the only copy they have. For Subversion to overwrite these
files, even if only when using --force, seems too harsh and doesn't
actually solve a problem anyone has(?).
I don't spend a lot of time reading the users list, but I suspect there
are a host of new users out there who could easily shoot themselves in the
foot with something like this. We can't save people from driving off the
cliff all the time, but we can at least throw up some guardrails. No?
Paul B.
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Takeover Take 2 Was: Re: the 'takeover' feature
Posted by Jonathan Gilbert <o2...@sneakemail.com>.
At 10:13 AM 18/04/2006 -0400, Michael Sweet wrote:
>Molle Bestefich wrote:
>> ...
>> Therefore I'd like to see a new subcommand, which would convert local
>> files into a working copy. That's exactly the same functionality that
>> Alan proposes: checkout BASE files and create .svn folders, but change
>> nothing else. Just for laughs, let's call this 'svn integrate'.
> > ...
>
>That sounds more like an option to "svn import" - basically, import
>the (current) directory into the specified repo and then do the
>equivalent of a checkout in that directory, e.g.:
>
> svn import --takeover http://foo.bar.com/myproject/trunk
>
>to import the current directory or:
>
> svn import --takeover myproject http://foo.bar.com/myproject/trunk
>
>to import the named directory and setup a WC there.
This is completely the opposite of the original reason I designed the feature.
I used to use (or should I say, be used by) Microsoft Visual SourceSafe. I
didn't know that it was bad; I knew it seemed a lot better than CVS, which
always looked too complicated and UNIX-oriented for me to bother to get
into. However, one day I read an article that described various ways in
which a SourceSafe repository can become corrupted -- in many cases,
unrecoverably so! I did some searching and found out that it was apparently
common knowledge, so I decided I had to switch to something else. Having
recently started development with the 'mono' project, who had just switched
to Subversion, and therefore having had some exposure to Subversion, I
chose Subversion as the replacement. The following were all factors in the
choice:
1. Free -- free of cost, free of guilt :-)
2. Reliable -- one of the most reliable from what I've read
3. Fast
4. Availability of a 'vss2svn' type script
So, here I was with a brand new completely empty Subversion repository and
a hard drive littered with Visual SourceSafe working copies, not all of
which were fully committed to the repository (i.e., some files were
partially modified and thus still checked out). I ran the script, and when
it was done, I had 300-some revisions in the Subversion repository,
including the complete change history with log messages of all projects,
with HEAD equal in every possible way to the latest revision of all the
SourceSafe projects.
A short while later, I had the need to make changes to one of the projects
under source control. I definitely didn't want to use SourceSafe, because
then I'd somehow have to resynchronize and it would be a big pain in the
ass and I was trying to get away from VSS anyway. So, I deleted the .scc
files and removed the +r attribute from the files, effectively cancelling
its VSS working copy status. Next step: make Subversion recognize it as a
working copy. "svn co". Nope, no go. Hmm.. where is the option I want? Hey,
what's going on here? There *is no way to turn this into a working copy*!
For that particular project, I did a checkout into a separate directory and
then moved the .svn metadata directories over one by one, by hand. After
the third project, though, that technique was starting to get a little bit
old. That was when I conceived of the "takeover" feature. I poked at the
Subversion source code and came up with the simplest way to implement it: I
noticed that "svn checkout" was implemented by simply creating empty
metadata files representing revision 0 and then doing an "svn update"
(exactly as though the user had typed "svn co -r 0" followed by "svn up").
I made my change by adding a flag to the internal implementation of the
"update" command to make it simply ignore existing files. The metadata
directory would still get its pristine copy, but the existing file would be
left alone -- after all, not all of the projects were in a committable
state when I did the switch to Subversion. I didn't actually know if it
would work, but I tried it, and sure enough, "svn status" showed those
files as locally modified. After completing those changes, "svn commit"
worked perfectly.
I actually neglected to handle existing subdirectories. I never noticed
this at the time because the majority of my projects are relatively small
and are all in one subdirectory. I've only had to "svn takeover" one
project since then, and while it was a bit of a pain in the arse, it didn't
really take too long. I simply did a non-recursive "takeover" (which,
modelled after "checkout", had inherited that option) of each subdirectory,
and then manually edited the "entries" files to include nodes for the
subdirectories.
As you can see, the use case for "takeover" has *nothing* to do with
putting files into the repository. The files are already there, for
whatever reason, and the local copy of the files -- possibly a working copy
from a previous version control system -- is similar to the server copy
*but may have changes*. For me, the fact that "update" would add missing
files automatically as part of my "takeover" operation was never a problem,
because I never actually *had* other files to be checked out that weren't
already in the local copy. I would be perfectly happy with a "takeover"
that didn't actually place missing files into the local copy, and instead
treated them as having been deleted. As I see it, though, such files should
be automatically scheduled for deletion in the repository; otherwise, the
working copy is inconsistent with the "entries" file and gets tagged, as
mentioned by a previous poster, with a '!' in "svn status".
Here is how I envision the various commands and their behaviours:
svn checkout
Shouldn't change; should still die with an error when an existing file is
found. If any change is to be done, it should be to automatically remove
files successfully added up to the point of the collision, returning the
filesystem to its state before the error was detected. However, I'm not at
all certain that this could be implemented in an efficient way. The most
efficient way I can think of would be to ask the server for another pass
over the same set of files (I vaguely remember that there's a way to do
this without actually receiving the files' contents) and cancel that
request when the erroneous file were reached. I don't have a strong opinion
about whether this overhead would be worth it.
svn checkout --force
Should blindly overwrite existing local files. A user using this option
should be well aware of this behaviour and not use it if he is worried
about losing local changes.
svn takeover / svn integrate
Should *only* set up metadata. A pristine copy is retrieved from the
server, and honestly I don't think bandwidth concerns are important at this
stage. Certainly, an rsync-like algorithm for this would violate
Subversion's consistency guarantees, in that, though it is very unlikely,
the rsync algorithm *can* incorrectly match blocks and generate corrupt
files. As I mentioned earlier, I feel that if the corresponding files are
missing from the repository, they should be automatically scheduled for
deletion.
I've also given it a bit of thought and believe that the output should be
more similar to "svn status" than "svn checkout", since the operation is
logically comparing the existing files with the pristine copy (albeit a
pristine copy that is in the very process of being dropped into place).
Perhaps something like:
box:/> svn takeover svn://server/source/trunk/project
T existing_unmodified_file
TM existing_unmodified_file_that_has_svn_properties
M existing_modified_file
TM existing_unmodified_file_that_has_svn_properties
A existing_file_not_in_repository
AM existing_binary_file_not_in_repository
D file_in_repository_missing_locally
DD this_situation_should_also_be_detectable
box:/>
Jonathan Gilbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Takeover Take 2 Was: Re: the 'takeover' feature
Posted by Molle Bestefich <mo...@gmail.com>.
Molle Bestefich wrote:
> You could accomplish what you want just as easily with my approach,
> so not much difference there.
Am I missing the point?
Do you want checkout to overwrite whatever local files might be
present, not merge with them?
In that case the extension of checkout (vs. a new command) makes much
more sense to me, and also the statement I made above would be wrong.
(--takeover would be a misnomer IMHO, --force if any would be more appropriate.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Takeover Take 2 Was: Re: the 'takeover' feature
Posted by Molle Bestefich <mo...@gmail.com>.
Mark Phippard wrote:
> Molle Bestefich wrote:
> > Unless you think I'm being totally ridiculous, I'd appreciate if you
> > could show me how to clearly document your variant of checkout?
>
> Doesn't it just come down to how one defines a "new working copy"?
Not sure. For me, checkout implicitly means fresh working copy.
Try the documentation dance I did. If you can make a concise and
clear description for newbie CLI users, I'll shut my yap about my
approach being cleaner :-).
> In my particular case, I am interested in this for Subclipse and our
> Eclipse integration. When we do a checkout, we have to first let Eclipse
> create some local project structure. This can often include some of the
> same files that are going to be checked out from the repository. So we
> have to look at everything Eclipse created, see if it is in the
> repository, and then delete it before starting the checkout. This is not
> too big of a problem, but there is also another common scenario that is a
> problem. For various reasons, someone disconnects their local project
> from SVN or maybe they are just starting with SVN and already have a copy
> of their project. They then want to connect it to SVN. Since the CVS
> plugin that comes with Eclipse allows all of this, they expect our plugin
> to do so as well. We can't provide this feature because we have no way of
> turning their local project into a working copy.
Super, thanks a lot, that explanation really helps when trying to
understand what you'd like to do.
> With this change to checkout, I could just do a checkout right on top
> of the local project and let things work themselves out.
You could accomplish what you want just as easily with my approach, so
not much difference there.
> Command line users have expressed the same desire, it particularly comes
> up as projects such as KDE migrate from CVS to SVN and all of the
> developers around the world want to just convert their local CVS working
> copy over to an SVN working copy. Ideally, they would also like it to do
> this intelligently and skip the download process as much as possible, but
> we are deferring that idea for now.
Same as above.
> As John Peacock pointed out, it might make sense to require the use of
> --force or some other switch to get this behavior. We can deal with that
> once we have the primary functionality actually working.
I've no preference.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Takeover Take 2 Was: Re: the 'takeover' feature
Posted by Mark Phippard <ma...@softlanding.com>.
"Molle Bestefich" <mo...@gmail.com> wrote on 04/18/2006 10:13:13
AM:
> Mark Phippard wrote:
> > I would argue that we are not introducing any confusing behavior that
> > will be hard to document.
>
> Ok. Perhaps we could dumb it down a bit - not because anyone here is
> dumb, but because testing the thesis would be the easiest way to end
> this particular discussion.
>
> I'd document "checkout" and "integrate" like this:
> ################
> checkout)
> Check out files from a repository into a new working copy.
>
> integrate)
> Convert local files to a working copy, given the URL of a repository
> path that the local files are supposed to match.
> ################
>
> Unless you think I'm being totally ridiculous, I'd appreciate if you
> could show me how to clearly document your variant of checkout?
Doesn't it just come down to how one defines a "new working copy"?
In my particular case, I am interested in this for Subclipse and our
Eclipse integration. When we do a checkout, we have to first let Eclipse
create some local project structure. This can often include some of the
same files that are going to be checked out from the repository. So we
have to look at everything Eclipse created, see if it is in the
repository, and then delete it before starting the checkout. This is not
too big of a problem, but there is also another common scenario that is a
problem. For various reasons, someone disconnects their local project
from SVN or maybe they are just starting with SVN and already have a copy
of their project. They then want to connect it to SVN. Since the CVS
plugin that comes with Eclipse allows all of this, they expect our plugin
to do so as well. We can't provide this feature because we have no way of
turning their local project into a working copy. With this change to
checkout, I could just do a checkout right on top of the local project and
let things work themselves out.
Command line users have expressed the same desire, it particularly comes
up as projects such as KDE migrate from CVS to SVN and all of the
developers around the world want to just convert their local CVS working
copy over to an SVN working copy. Ideally, they would also like it to do
this intelligently and skip the download process as much as possible, but
we are deferring that idea for now.
As John Peacock pointed out, it might make sense to require the use of
--force or some other switch to get this behavior. We can deal with that
once we have the primary functionality actually working.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Takeover Take 2 Was: Re: the 'takeover' feature
Posted by Molle Bestefich <mo...@gmail.com>.
Mark Phippard wrote:
> I would argue that we are not introducing any confusing behavior that
> will be hard to document.
Ok. Perhaps we could dumb it down a bit - not because anyone here is
dumb, but because testing the thesis would be the easiest way to end
this particular discussion.
I'd document "checkout" and "integrate" like this:
################
checkout)
Check out files from a repository into a new working copy.
integrate)
Convert local files to a working copy, given the URL of a repository
path that the local files are supposed to match.
################
Unless you think I'm being totally ridiculous, I'd appreciate if you
could show me how to clearly document your variant of checkout?
Hope I'm not too far out :-).
> I'd also hate to see this improvement get derailed again.
Of course, me too, I'm really sorry if it seems like that's what I'm
trying to do :-/.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Takeover Take 2 Was: Re: the 'takeover' feature
Posted by John Peacock <jp...@rowman.com>.
Mark Phippard wrote:
> Checkout currently does #1, this would change it to #3. Part of doing #3
> means sliding the .svn metdata under the existing file so that you can
> then use normal svn commands, such as commit or revert to deal with the
> local file.
I just want to make sure that everyone understands that I *love* the
idea for the takeover feature. I am also guilty of tarring up a
directory tree to copy some files to another machine and then later
regretting that and adding the files to a repository and having to deal
with the localized drift manually.
The only thing I am -0 on this feature is making it the default
behavior. I believe it is much more appropriate to loudly inform the
user that svn is lightly stepping around existing files, rather than
performing a /tabula rasa/ checkout. Since the project doesn't like CLI
prompts:
Existing files found; continue checkout? [Y/N]
then the only way to mandate an alert to the user is to error out the
first time:
Existing files found; did you mean 'checkout --takeover'?
(with whatever flag for checkout is chosen).
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: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Takeover Take 2 Was: Re: the 'takeover' feature
Posted by Mark Phippard <ma...@softlanding.com>.
"Molle Bestefich" <mo...@gmail.com> wrote on 04/18/2006 09:44:37
AM:
> Molle Bestefich wrote:
> > Checkout is designed for "checking something fresh out of the
> > repository", not "converting local files to a working copy".
>
> I would HATE to see Subversion attain the command set hell that GIT
> has. OTOH I think that lumping these two logically disparate user
> actions into one subcommand makes as much sense as, say, removing the
> 'checkout' command and making that a special flag to 'update'.
>
> Sure, the code path is probably basically the same, but from a user
> POV, there's a world of difference.
The argument to making this change has been that the current checkout
behavior is not what is expected. What it comes down to is that there are
three possibilities for what a theoretical checkout process could do if a
file it is checking out already exists locally:
1) Abort the process
2) Replace the file with the one from the repository
3) Leave the existing file, and continue the process
Checkout currently does #1, this would change it to #3. Part of doing #3
means sliding the .svn metdata under the existing file so that you can
then use normal svn commands, such as commit or revert to deal with the
local file.
So I would argue that we are not introducing any confusing behavior that
will be hard to document. We are just removing an obstacle to succefully
using Subversion.
I like your svn integrate idea as well, I just think it is a separate
issue. I'd also hate to see this improvement get derailed again.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Takeover Take 2 Was: Re: the 'takeover' feature
Posted by Molle Bestefich <mo...@gmail.com>.
Molle Bestefich wrote:
> Checkout is designed for "checking something fresh out of the
> repository", not "converting local files to a working copy".
I would HATE to see Subversion attain the command set hell that GIT
has. OTOH I think that lumping these two logically disparate user
actions into one subcommand makes as much sense as, say, removing the
'checkout' command and making that a special flag to 'update'.
Sure, the code path is probably basically the same, but from a user
POV, there's a world of difference.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Takeover Take 2 Was: Re: the 'takeover' feature
Posted by Molle Bestefich <mo...@gmail.com>.
Molle Bestefich wrote:
> Michael Sweet wrote:
> > That sounds more like an option to "svn import" - basically, import
> > the (current) directory into the specified repo [...]
>
> I wouldn't mind skipping the WC entirely and instead diff against BASE
> on the spot while generating the commit. I don't know the import code
> good enough to tell if your proposal is feasible.
>
> The code to do this would be more complicated. For example, it has to
> handle a number of situations gracefully, such as
> files-turned-to-directories, to be useful for my backup purposes.
Not to mention that the svn process would run out of RAM almost immediately.
I don't think the 'import' idea is feasible, it has to go through a
working copy first.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Takeover Take 2 Was: Re: the 'takeover' feature
Posted by Peter Samuelson <pe...@p12n.org>.
[Michael Sweet]
> It sounds more like you want to manage them as a "vendor branch"
> but not actually use them "live" from the repo. I *think* there
> is a Python script included with Subversion that might already do
> what you want, but nothing is jumping out at me when I look...
svn_load_dirs.pl? It doesn't do exactly that, but it seems to serve a
similar purpose.
Re: Takeover Take 2 Was: Re: the 'takeover' feature
Posted by Michael Sweet <mi...@easysw.com>.
Molle Bestefich wrote:
> Michael Sweet wrote:
>> Molle Bestefich wrote:
>>> Therefore I'd like to see a new subcommand, which would convert local
>>> files into a working copy. That's exactly the same functionality that
>>> Alan proposes: checkout BASE files and create .svn folders, but change
>>> nothing else. Just for laughs, let's call this 'svn integrate'.
>> > ...
>>
>> That sounds more like an option to "svn import" - basically, import
>> the (current) directory into the specified repo [...]
>
> I wouldn't mind skipping the WC entirely and instead diff against BASE
> on the spot while generating the commit. I don't know the import code
> good enough to tell if your proposal is feasible.
>
> The code to do this would be more complicated. For example, it has to
> handle a number of situations gracefully, such as
> files-turned-to-directories, to be useful for my backup purposes.
>
>> svn import --takeover http://foo.bar.com/myproject/trunk
>
> I think --takeover would be a bad name for your proposal, at least if
> you still think it should be suitable for my needs.
>
> '--replace' is better IMO, it indicates that the entire structure in
> the repository should be replaced, including deleting files that
> doesn't exist in the folder you're pointing 'import' at.
OK, then we *are* thinking of two separate use cases, then.
I thought you wanted to start with an existing directory containing
config files/whatever and import them into a Subversion repo so that
they would be managed/versioned by Subversion.
It sounds more like you want to manage them as a "vendor branch"
but not actually use them "live" from the repo. I *think* there
is a Python script included with Subversion that might already do
what you want, but nothing is jumping out at me when I look...
>> [...] and then do the equivalent of a checkout in that directory
>
> I have no use of the checkout once the changes have been committed to
> the repository.
> (I don't see how starting to checkout files fit with the 'import'
> concept either..)
>
>> to import the named directory and setup a WC there.
>
> I have zero interest in setting up the WC after commit time, so that
> wouldn't work for me.
>
>> Also, if checkout gets support for --takeover, it should be super-
>> easy to add it to import as well.
>
> Really?
Yes, it would amount to import and then checkout in the same
directory.
--
______________________________________________________________________
Michael Sweet, Easy Software Products mike at easysw dot com
Internet Printing and Document Software http://www.easysw.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Takeover Take 2 Was: Re: the 'takeover' feature
Posted by Molle Bestefich <mo...@gmail.com>.
Michael Sweet wrote:
> Molle Bestefich wrote:
> > Therefore I'd like to see a new subcommand, which would convert local
> > files into a working copy. That's exactly the same functionality that
> > Alan proposes: checkout BASE files and create .svn folders, but change
> > nothing else. Just for laughs, let's call this 'svn integrate'.
> > ...
>
> That sounds more like an option to "svn import" - basically, import
> the (current) directory into the specified repo [...]
I wouldn't mind skipping the WC entirely and instead diff against BASE
on the spot while generating the commit. I don't know the import code
good enough to tell if your proposal is feasible.
The code to do this would be more complicated. For example, it has to
handle a number of situations gracefully, such as
files-turned-to-directories, to be useful for my backup purposes.
> svn import --takeover http://foo.bar.com/myproject/trunk
I think --takeover would be a bad name for your proposal, at least if
you still think it should be suitable for my needs.
'--replace' is better IMO, it indicates that the entire structure in
the repository should be replaced, including deleting files that
doesn't exist in the folder you're pointing 'import' at.
> [...] and then do the equivalent of a checkout in that directory
I have no use of the checkout once the changes have been committed to
the repository.
(I don't see how starting to checkout files fit with the 'import'
concept either..)
> to import the named directory and setup a WC there.
I have zero interest in setting up the WC after commit time, so that
wouldn't work for me.
> Also, if checkout gets support for --takeover, it should be super-
> easy to add it to import as well.
Really?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Takeover Take 2 Was: Re: the 'takeover' feature
Posted by Michael Sweet <mi...@easysw.com>.
Molle Bestefich wrote:
> ...
> Therefore I'd like to see a new subcommand, which would convert local
> files into a working copy. That's exactly the same functionality that
> Alan proposes: checkout BASE files and create .svn folders, but change
> nothing else. Just for laughs, let's call this 'svn integrate'.
> ...
That sounds more like an option to "svn import" - basically, import
the (current) directory into the specified repo and then do the
equivalent of a checkout in that directory, e.g.:
svn import --takeover http://foo.bar.com/myproject/trunk
to import the current directory or:
svn import --takeover myproject http://foo.bar.com/myproject/trunk
to import the named directory and setup a WC there.
Mind you, this isn't something I do every day, but I *do* do the
equivalent of this probably once a month when I start a new
project (svn import foo; mv foo foo.old; svn co foo; verify foo;
rm -f foo.old). Support for this would save me a bunch of steps...
Also, if checkout gets support for --takeover, it should be super-
easy to add it to import as well.
--
______________________________________________________________________
Michael Sweet, Easy Software Products mike at easysw dot com
Internet Printing and Document Software http://www.easysw.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Takeover Take 2 Was: Re: the 'takeover' feature
Posted by Molle Bestefich <mo...@gmail.com>.
Paul Burba wrote:
> I thought you were referring to Alan's proposal:
>
> Alan Barrett wrote:
> > Mark Phippard wrote:
> > > Files that do not exist locally but do in the repository would
> > > be added locally and show as unmodified.
> >
> > I don't want that. I want the file to show as deleted locally ("!" in
> > output from "svn status"). Later, I can choose whether to add the file
> > locally (svn revert filename) or delete the file in the repository (svn
> > delete filename ; svn commit filename).
I was.
> If so, that is not what we're proposing. We just want checkout to
> tolerate existing files/directories, as described here in the last post on
> this topic before "take 2":
>
> Greg Hudson wrote:
> > > > I think checkout should tolerate existing directories by default.
>
> That's really it in a nutshell. Does that clear things up at all?
Sort of, yes.
I think your proposal is very fine indeed, let me just clarify that point.
But I'd like to bend things a bit differently anyway. Mainly because
I also use Subversion for incremental backups, but also because I
think it would be "cleaner".
I'll elaborate on the backup thingy, you may skip this if you find it boring.
We currently do this:
* Create a snapshot of the volume to be backed-up
* Checkout HEAD of backup repository into a new folder
* Copy files from snapshot on top of checkout
* Remove WC files from checkout that doesn't exist in snapshot anymore
* Commit
We currently duplicate a lot of code that Subversion also has, for
example to detect whether a file has changed into a directory since
the last backup, and it's also quite inefficient because we do a lot
of copying around and we have to delete WC files from 'svn co' that
doesn't exist in the real filesystem anymore.
Therefore I'd like to see a new subcommand, which would convert local
files into a working copy. That's exactly the same functionality that
Alan proposes: checkout BASE files and create .svn folders, but change
nothing else. Just for laughs, let's call this 'svn integrate'.
Then we could drop all of our backup code and just do:
* Create a snapshot of the volume to be backed-up
* 'svn integrate' to convert that to a working copy
* Commit
Assuming the new 'integrate' command, what you want *could* then be
achieved by 'svn integrate' and then 'svn up'. Correct?
I also happen to think that 'svn integrate' and 'svn up' is a much
"cleaner" approach for what you guys want to do. By "cleaner", I mean
that:
Checkout is designed for "checking something fresh out of the
repository", not "converting local files to a working copy".
When I think about modifying checkout the way you propose, I think
about how it would look in documentation. And I cannot think of a way
to explain the checkout behaviour you propose in a concise and clear
manner to users, while the 'integrate' feature seems a no-brainer to
me.
I'm in _no_ way hellbent on seeing things progress the way I'd like,
but I hope I can explain why I think it would be both prettier and
more useful.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Takeover Take 2 Was: Re: the 'takeover' feature
Posted by Mark Phippard <ma...@softlanding.com>.
Paul Burba <pa...@softlanding.com> wrote on 04/18/2006 08:39:42 AM:
> And just to be clear, we interpret this this way:
>
> If you checkout into a non-empty directory:
>
> svn co <URL> <WCPATH>
>
> It behaves exactly the same as co does now, with one exception:
>
> 1) If a path/name from <URL> already exists in <WCPATH> we keep the
latter
> and it's status is modified (rather than the whole co failing).
Just to clarify one point, the status would only be modified if the
existing file is different. Basically, once the co is complete, normal
SVN behavior takes over.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Takeover Take 2 Was: Re: the 'takeover' feature
Posted by Paul Burba <pa...@softlanding.com>.
"Molle Bestefich" <mo...@gmail.com> wrote on 04/17/2006 07:51:07
PM:
> Paul Burba wrote:
> > > What Alan outlines sounds much cleaner and much more useful,
> > > even if it does require a new subcommand.
> >
> > ...again I think this functionality would be in addition to what I'm
> > doing, not a replacement for it. No?
>
> I figured that what you want sounds exactly like Alan's cleaner
> variant of 'takeover', with 'svn up' afterwards to recreate the files
> in WC that are marked as missing.
>
> Am I completely off the track? :-)
Hi Molle,
I think we are just on different tracks :-)
I thought you were referring to Alan's proposal:
Alan Barrett <ap...@cequrux.com> wrote on 04/15/2006 10:04:10 AM:
> On Sat, 15 Apr 2006, Mark Phippard wrote:
> > Files that do not exist locally but do in the repository would
> > be added locally and show as unmodified.
>
> I don't want that. I want the file to show as deleted locally ("!" in
> output from "svn status"). Later, I can choose whether to add the file
> locally (svn revert filename) or delete the file in the repository (svn
> delete filename ; svn commit filename).
If so, that is not what we're proposing. We just want checkout to
tolerate existing files/directories, as described here in the last post on
this topic before "take 2":
> kfogel@newton.ch.collab.net wrote on 09/16/2005 06:20:36 PM:
>
> > Greg Hudson <gh...@MIT.EDU> writes:
> > > Well, I'm not part of this consensus.
> > >
> > > I think checkout should tolerate existing directories by default. No
> > > need for a flag for that. That should alleviate that Eclipse use
> case.
> >
> > Yes -- in fact, I thought this was the conclusion we came to earlier
> > (though the thread has been long, and I don't blame anyone for
> > forgetting a later conclusion and backtracking to an earlier one).
> >
> > +1 on checkout just Doing The Right Thing when invoked over an
> > existing local tree, by default. No need for a new switch here.
> >
> > -Karl
And just to be clear, we interpret this this way:
If you checkout into a non-empty directory:
svn co <URL> <WCPATH>
It behaves exactly the same as co does now, with one exception:
1) If a path/name from <URL> already exists in <WCPATH> we keep the latter
and it's status is modified (rather than the whole co failing).
That's really it in a nutshell. Does that clear things up at all? Or am
I off track and at the bottom of a ravine at this point?
Let me know,
Paul B.
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Takeover Take 2 Was: Re: the 'takeover' feature
Posted by Molle Bestefich <mo...@gmail.com>.
Paul Burba wrote:
> > What Alan outlines sounds much cleaner and much more useful,
> > even if it does require a new subcommand.
>
> ...again I think this functionality would be in addition to what I'm
> doing, not a replacement for it. No?
I figured that what you want sounds exactly like Alan's cleaner
variant of 'takeover', with 'svn up' afterwards to recreate the files
in WC that are marked as missing.
Am I completely off the track? :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PROPOSAL] Takeover Take 2 Was: Re: the 'takeover' feature
Posted by Mark Phippard <ma...@softlanding.com>.
John Peacock <jp...@rowman.com> wrote on 04/14/2006 04:07:35 PM:
> Paul Burba wrote:
> > Pouring over the takeover threads there seems to be a consensus that
> > checkout is the place for this functionality and that further
> > optimizations/improvements can wait. There is less agreement on the
> > question of whether co needs a new option --takeover, should use
--force,
> > or should just behave this way by default (my vote if for the last
> > option).
>
> Just to confuse the matter, I'm still of the opinion that checkout
should not
> silently absorb a pre-existing directory tree. I think that, although
that
> would be convenient for certain situations (I believe the Eclipse case
was
> mentioned repeatedly), it has the (to my mind) distinct disadvantage
that it
> loses information. Implicitely, conversion of a directory tree from
plain files
> to a working copy "loses" the information that this was not a working
copy to
> begin with.
>
> If the eventual result is that files with the same name/path as in the
> repository will be automatically "added" and changes from the repository
version
> will show up as [M]odified, that's one thing. But how would the various
WC
> special flags be interpreted:
>
> 1) a file on disk is executable, but in the repository isn't tagged as
> svn:executable, what happens?
>
> 2) the reverse of 1 (svn:executable is set but the existing file isn't)?
>
> 3) svn:ignores filters file out of the absorbed tree (this is probably
harmless
> since the file could be manually added when the ? status was noticed)?
My opinion was that these three things have to somewhat be non issues
because there is nothing stopping someone today from renaming a local
folder, checking out a project, and then copying everything over the top.
This is what Subclipse users wanted us to do for them (but we do not). If
someone did this, Subversion would deal with it. You could of course
argue that if you did this yourself you have to expect to suffer whatever
side-effects ensue, versus doing it via checkout.
> I'd personally advocate that --force be required to absorb existing
files into a
> in-place checkout, but it would be nice to have a .subversion/config
setting
> that made that the default (for those who wants it)...
I do not care if it requires --force or not. Subclipse can supply the
flag so long as JavaHL exposes it to us. I think it was ghudson, kfogel
and several others who thought this should be the default, without needing
--force. I happen to agree, but would not mind if there were a switch.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PROPOSAL] Takeover Take 2 Was: Re: the 'takeover' feature
Posted by Paul Burba <pa...@softlanding.com>.
Hi John/Alan/Molle,
As you all likely recall from the various "Takeover" threads, this topic
was sidelined once before due to disagreement over new or existing
subcommand, existing option, new option or no option, bandwith
optimizations, tastes great or less filling, etc., etc..
I'd really like to avoid that this time around and humbly ask for some
time to get my patch working. That said, here's my 2 cents re some of
your concerns:
John Peacock <jp...@rowman.com> wrote on 04/14/2006 04:07:35 PM:
> Paul Burba wrote:
> > Pouring over the takeover threads there seems to be a consensus that
> > checkout is the place for this functionality and that further
> > optimizations/improvements can wait. There is less agreement on the
> > question of whether co needs a new option --takeover, should use
--force,
> > or should just behave this way by default (my vote if for the last
> > option).
>
> I'd personally advocate that --force be required to absorb existing
> files into a
> in-place checkout, but it would be nice to have a .subversion/config
setting
> that made that the default (for those who wants it)...
As Mark mentioned there is good support for making this the default. That
said, the hard part (for me at least) is making it work at all, if it's
eventually decided to go with --force that sould be easy to do.
Alan Barrett <ap...@cequrux.com> wrote on 04/15/2006 12:59:13 PM:
> On Sat, 15 Apr 2006, Mark Phippard wrote:
> > > I don't want that. I want the file to show as deleted locally ("!"
> > > in output from "svn status"). Later, I can choose whether to add
> > > the file locally (svn revert filename) or delete the file in the
> > > repository (svn delete filename ; svn commit filename).
> >
> > I think it would have to be a different subcommand to work that way,
>
> Why not just a different option to svn checkout?
Whether it's a different subcommand or another option to svn co, this is
really a separate feature IMHO.
"Molle Bestefich" <mo...@gmail.com> wrote on 04/16/2006 07:09:19
PM:
> If 'svn co --takeover' is not good enough and it really does warrant a
> new subcommand, then perhaps people will just need to get over it and
> add one.
Agreed, but...
> What Alan outlines sounds much cleaner and much more useful, even if
> it does require a new subcommand.
...again I think this functionality would be in addition to what I'm
doing, not a replacement for it. No?
Paul B.
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PROPOSAL] Takeover Take 2 Was: Re: the 'takeover' feature
Posted by John Peacock <jp...@rowman.com>.
Paul Burba wrote:
> Pouring over the takeover threads there seems to be a consensus that
> checkout is the place for this functionality and that further
> optimizations/improvements can wait. There is less agreement on the
> question of whether co needs a new option --takeover, should use --force,
> or should just behave this way by default (my vote if for the last
> option).
Just to confuse the matter, I'm still of the opinion that checkout should not
silently absorb a pre-existing directory tree. I think that, although that
would be convenient for certain situations (I believe the Eclipse case was
mentioned repeatedly), it has the (to my mind) distinct disadvantage that it
loses information. Implicitely, conversion of a directory tree from plain files
to a working copy "loses" the information that this was not a working copy to
begin with.
If the eventual result is that files with the same name/path as in the
repository will be automatically "added" and changes from the repository version
will show up as [M]odified, that's one thing. But how would the various WC
special flags be interpreted:
1) a file on disk is executable, but in the repository isn't tagged as
svn:executable, what happens?
2) the reverse of 1 (svn:executable is set but the existing file isn't)?
3) svn:ignores filters file out of the absorbed tree (this is probably harmless
since the file could be manually added when the ? status was noticed)?
I'd personally advocate that --force be required to absorb existing files into a
in-place checkout, but it would be nice to have a .subversion/config setting
that made that the default (for those who wants it)...
John
--
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
Re: [PROPOSAL] Takeover Take 2 Was: Re: the 'takeover' feature
Posted by Ivan Zhakov <ch...@gmail.com>.
On 4/14/06, Paul Burba <pa...@softlanding.com> wrote:
> Paul Burba <pa...@softlanding.com> wrote on 04/11/2006 04:16:02 PM:
>
> > Hi All,
> >
> > Just wondering what ever became of takeover...does it still have any
> life?
> > As Mark has mentioned a few times in the thread, this would be very
> > helpful re Subclipse.
> >
> > I'm glad to attempt any grunt work required to get Jonathan's old 1.2
> > patch caught up to trunk if that's all that's holding this up.
> >
> > Please let me know, thanks,
> >
> > Paul B.
> >
> > kfogel@newton.ch.collab.net wrote on 09/16/2005 06:20:36 PM:
> >
> > > Greg Hudson <gh...@MIT.EDU> writes:
> > > > Well, I'm not part of this consensus.
> > > >
> > > > I think checkout should tolerate existing directories by default. No
> > > > need for a flag for that. That should alleviate that Eclipse use
> > case.
> > >
> > > Yes -- in fact, I thought this was the conclusion we came to earlier
> > > (though the thread has been long, and I don't blame anyone for
> > > forgetting a later conclusion and backtracking to an earlier one).
> > >
> > > +1 on checkout just Doing The Right Thing when invoked over an
> > > existing local tree, by default. No need for a new switch here.
> > >
> > > -Karl
>
> I didn't hear from anyone so I'd like to push this forward.
>
> Pouring over the takeover threads there seems to be a consensus that
> checkout is the place for this functionality and that further
> optimizations/improvements can wait. There is less agreement on the
> question of whether co needs a new option --takeover, should use --force,
> or should just behave this way by default (my vote if for the last
> option). I'm going to start work shortly on a patch to trunk based on
> Jonathan's 1.2.0 patch. If anyone out there has strong objections or
> something to add please let me know.
>
Good idea, please do it!
--
Ivan Zhakov