You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Julian Foad <ju...@btopenworld.com> on 2003/11/12 19:52:51 UTC
Abolish instant-commit commands [was: Re: The right library...to
get info about a directory]
Files wrote:
>
> I'd also, really like to be able to do 'svn edit
> http://myrepos.com/repos/svn/testfile.txt --message "mymessage" -F myfile.txt'
> or 'svn edit http://myrepos.com/repos/svn/testfile.txt --message "mymessage" <
> myfile.txt'.
What would you like those commands to do? I assume you would want them to make a commit which modifies "testfile.txt" to contain the text from "myfile.txt", but what properties? No properties? The properties from "testfile.txt@HEAD"? The properties from some other, optionally specified revision? And if you wanted to change the properties as well, would you use "propset" (or "propedit") to make a separate commit? Or would you want a way of changing the properties in the same commit? If you want to change more than one file, are you happy to use a separate commit for each file that you change in this way?
I don't like it at all. Perhaps the precedent for your proposal is the existence of commands like "propset NAME VALUE URL..." and "mkdir URL" which cause an instant commit. I would go the opposite way, and vote to abolish such instant commits. Those commands are useful in some limited circumstances, and your proposal IS a logical extension of them, but they all head away from Subversion's basis of "one commit per logical change".
For instance, there is an argument that "svn mkdir URL" is useful to make a branch directory. Of course it is, in the limited circumstance of not wanting any properties set on that new directory. As soon as you go beyond the simple, the idea falls apart.
Even "import" is, in my view, a bad idea. Normally one finds that one wants properties set or unset on files that are being imported, or wants to remove certain files from the import. The ideal way to do this would be to "svn add" (in place or to another local directory which would become the WC), and then have the opportunity to modify properties, remove files, etc., before making the initial commit. I know that "import" is "expected" by CVS converts, but I would prefer an "import to WC" which is the opposite of "export from WC".
Thoughts on reducing the set of "instant commit" commands to the bare essentials?
Thoughts on "import to WC"?
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Non-recursive checkout is broken?
Posted by Philip Martin <ph...@codematters.co.uk>.
Julian Foad <ju...@btopenworld.com> writes:
> Philip Martin wrote:
>> Julian Foad <ju...@btopenworld.com> writes:
>>
>>>After a non-recursive checkout
>> Issue 695.
>
> Issue 695 is '"svn checkout --nonrecursive" should be sticky'.
"svn checkout --nonrecursive" is broken and should be fixed or removed.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Non-recursive checkout is broken?
Posted by Julian Foad <ju...@btopenworld.com>.
Philip Martin wrote:
> Julian Foad <ju...@btopenworld.com> writes:
>
>>After a non-recursive checkout
>
> Issue 695.
Issue 695 is '"svn checkout --nonrecursive" should be sticky'.
My point is the opposite: that "svn checkout --nonrecursive" is so sticky that I can't unstick it and get any subdirectories to appear by any means.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Non-recursive checkout is broken?
Posted by Philip Martin <ph...@codematters.co.uk>.
Julian Foad <ju...@btopenworld.com> writes:
> After a non-recursive checkout
Issue 695.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Non-recursive checkout is broken?
Posted by Julian Foad <ju...@btopenworld.com>.
After a non-recursive checkout (which gets all of the files but none of the subdirectories) I have not managed to get a subdirectory from the repository into my WC. I tried "svn update subdir" and "svn copy URL subdir" and "svn checkout URL subdir". The test script is attached, and the output, starting from after the checkout, is shown below.
I would expect that "status -vu" would show that the subdirectory would be added by an update, either by marking the parent entry (".") with an asterisk or by showing a status entry for "subdir" with an asterisk.
+ svn list -vR
1 julianfo 6 Nov 15 15:54 file
1 julianfo Nov 15 15:54 subdir/
1 julianfo 6 Nov 15 15:54 subdir/file
+ svn status -vu
1 1 julianfoad .
1 1 julianfoad file
Status against revision: 1
+ svn update subdir
svn: warning: svn_wc_is_wc_root: 'subdir' is not a versioned resource
+ svn copy file:///home/julianfoad/tmp/incomplete-wc/repos/subdir .
/home/julianfoad/src/subversion/subversion/libsvn_wc/lock.c:165: (apr_err=155004)
svn: Attempted to lock an already-locked dir
svn: working copy locked: .
svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details)
+ svn checkout file:///home/julianfoad/tmp/incomplete-wc/repos/subdir
/home/julianfoad/src/subversion/subversion/libsvn_wc/lock.c:600: (apr_err=155005)
svn: Working copy not locked
svn: directory 'subdir' not locked
Each of "copy" and "checkout" creates a directory "subdir" and "subdir/.svn", but does not integrate it into its parent or populate it. The WC is not reported as Locked before or after these attempts.
I am not saying that all three of these methods should be valid ways to get the subdirectory, but I think at least "copy" and/or "update" should be. Perhaps I'm not trying the right way?
- Julian
Re: Working with incomplete WC, or no WC [was: Re: Abolish
instant-commit commands]
Posted by Greg Hudson <gh...@MIT.EDU>.
On Sat, 2003-11-15 at 11:06, Julian Foad wrote:
> My point is that if the action that you want to perform is not a
> single copy or propset or mkdir, but a combination of any two or more
> of those (e.g. you want to set a custom property on your branch) then
> the instant-commit syntax cannot do it in one commit. We ought to
> consider providing some mechanism for building up a multi-part
> transaction without a working copy - or at least without a complete
> working copy.
Ah, yes. See
http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgId=188086
for an example proposal involving long-lived transactions.
One could, alternatively, do all the work on the client. "svn cp" could
have an option, perhaps just -N, to avoid populating the area being
copied to, or we could have a thing for queuing up operations
client-side without reflecting them in a working copy, and committing
them all at once. Big design space here.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Working with incomplete WC, or no WC [was: Re: Abolish
instant-commit commands]
Posted by Ben Collins-Sussman <su...@collab.net>.
On Sat, 2003-11-15 at 10:06, Julian Foad wrote:
> We ought to consider providing some mechanism for building up a
> multi-part transaction without a working copy - or at least without a
> complete working copy.
Ha, welcome to DeltaV. It has a whole model for server-side working
copies, we just happen to ignore it right now. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Working with incomplete WC, or no WC [was: Re: Abolish instant-commit
commands]
Posted by Julian Foad <ju...@btopenworld.com>.
Branko Čibej wrote:
> Julian Foad wrote:
>
>>For instance, there is an argument that "svn mkdir URL" is useful to
>>make a branch directory. Of course it is, in the limited circumstance
>>of not wanting any properties set on that new directory. As soon as
>>you go beyond the simple, the idea falls apart.
>
> Uh. Compare this:
>
> svn cp http://svn.collab.net/repos/svn/trrunk \
> http://svn.collab.net/repos/svn/branches/issue-xxx-dev
>
> and this:
>
> svn co http://svn.collab.net/repos/svn
> cd svn
> svn cp trunk branches/issue-xxx-dev
> svn ci
... your point being, presumably, that the second version requires so much data transfer as to make it impractical, and a bit more typing too.
OK, I was being over-dramatic when I suggested "abolishing" the existing instant-commit commands. I concede that it is necessary to have a way to do operations like this directly on the repository and, for the time being, those commands are the means to do it.
My point is that if the action that you want to perform is not a single copy or propset or mkdir, but a combination of any two or more of those (e.g. you want to set a custom property on your branch) then the instant-commit syntax cannot do it in one commit. We ought to consider providing some mechanism for building up a multi-part transaction without a working copy - or at least without a complete working copy.
"svn checkout --non-recursive" is probably the way to go, but I am not sure to what extent Subversion can cope with an incomplete working copy through a full cycle of checkout+modify+commit. I got stuck at the first hurdle: after a non-recursive checkout (which gets all of the files but none of the subdirectories) I have not managed to get a subdirectory. I tried "svn update subdir" and "svn copy URL subdir" and "svn checkout URL subdir". The test script is attached, and the output from these attempts is shown below.
+ svn list -vR
1 julianfo 6 Nov 15 15:54 file
1 julianfo Nov 15 15:54 subdir/
1 julianfo 6 Nov 15 15:54 subdir/file
+ svn status -vu
1 1 julianfoad .
1 1 julianfoad file
Status against revision: 1
+ svn update subdir
svn: warning: svn_wc_is_wc_root: 'subdir' is not a versioned resource
+ svn copy file:///home/julianfoad/tmp/incomplete-wc/repos/subdir .
/home/julianfoad/src/subversion/subversion/libsvn_wc/lock.c:165: (apr_err=155004)
svn: Attempted to lock an already-locked dir
svn: working copy locked: .
svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details)
+ svn checkout file:///home/julianfoad/tmp/incomplete-wc/repos/subdir
/home/julianfoad/src/subversion/subversion/libsvn_wc/lock.c:600: (apr_err=155005)
svn: Working copy not locked
svn: directory 'subdir' not locked
Each of "copy" and "checkout" creates a directory "subdir" and "subdir/.svn", but does not integrate it into its parent or populate it. The WC is not reported as Locked before or after these attempts.
Perhaps this is possible but I'm not trying the right way?
- Julian
Re: Abolish instant-commit commands [was: Re: The right library...to
get info about a directory]
Posted by Branko Čibej <br...@xbc.nu>.
Julian Foad wrote:
> For instance, there is an argument that "svn mkdir URL" is useful to
> make a branch directory. Of course it is, in the limited circumstance
> of not wanting any properties set on that new directory. As soon as
> you go beyond the simple, the idea falls apart.
Uh. Compare this:
svn cp http://svn.collab.net/repos/svn/trrunk \
http://svn.collab.net/repos/svn/branches/issue-xxx-dev
and this:
svn co http://svn.collab.net/repos/svn
cd svn
svn cp trunk branches/issue-xxx-dev
svn ci
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Abolish instant-commit commands [was: Re: The right library...toget
info about a directory]
Posted by Julian Foad <ju...@btopenworld.com>.
Files wrote:
> I understand what you're saying. I do see your point of view.
>
> I'll take any suggestions you have for remote repository file maintenance.
>
> E.g. webdav et al.
>
> My repository browser allows regular filesystems and a subversion repository
> to appear seamlessly interconnected. I am wondering how I should proceed to
> allow users to to edit the contents of said repository via the same web
> interface that they would regular files.
If you want a system in which every individual change causes a commit, then you should hook into the Subversion libraries directly. The Subversion command-line client is not designed to operate in this mode, even though it has some commands that can make an instant commit.
> Which in essence is how webdav works, if I'm not mistaken.
I don't know anything about WebDAV except that Subversion uses a subset of its protocol.
> If the repository exists on the local box, I can use wc. But my repository
> browser allows for:
>
> http://www.svnexplorer.somesite.com/http/svn.someothersite.com/repos/myfiles
>
> How should I handle that using the existing subversion framework without the
> instant commits?
I don't know. Maybe make a temporary local working copy?
> I'll follow any lead you can give me.
I can help with some of the questions that directly affect the Subversion project, but cannot give you much help in designing your browser.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Abolish instant-commit commands [was: Re: The right
library...toget info about a directory]
Posted by Files <fi...@poetryunlimited.com>.
I understand what you're saying. I do see your point of view.
I'll take any suggestions you have for remote repository file maintenance.
E.g. webdav et al.
My repository browser allows regular filesystems and a subversion repository
to appear seamlessly interconnected. I am wondering how I should proceed to
allow users to to edit the contents of said repository via the same web
interface that they would regular files.
Which in essence is how webdav works, if I'm not mistaken.
If the repository exists on the local box, I can use wc. But my repository
browser allows for:
http://www.svnexplorer.somesite.com/http/svn.someothersite.com/repos/myfiles
How should I handle that using the existing subversion framework without the
instant commits?
I'll follow any lead you can give me.
--
Shamim Islam
BA BS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org