You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Dirk Hoffmann <dh...@web.de> on 2004/09/01 06:47:04 UTC
Re: Checkin without working copy
Ben Collins-Sussman wrote:
> Dirk Hoffmann wrote:
>
>
>> I looked at several files in the 'include' dir particularly at
>> `svn_ra.h' and also at files under `libsvn_ra' and `libsvn_ra_dav'
>> but couldn't find there any appropriate stuff. There were a lot of
>> function declarations dealing with properties and also `get_file()'
>> and `get_dir()', but no equivalent for "put_file()".
>>
>> Also the docs, say nothing about how to checkin a file without a
>> working copy.
>>
>> But maybe I'm looking at the wrong places.
>>
>
> RA->get_commit_editor() is the way to commit a new revision.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
Ah, cool, that's what I need. Thanks a lot.
So I will definitely extend the javahl API to allow committing files
without needing a wc.
Unforunately I haven't found much about how to utilize a commit editor.
Could you give me some pointers on this please.
Regards,
Dirk
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Checkin without working copy
Posted by "C. Michael Pilato" <cm...@collab.net>.
Joel Shellman <jo...@ikestrel.com> writes:
> Taking that a step further, your utility could accept a rev number on
> the command line and check to make sure that it was creating the
> successive rev number to the one given, (if the API supported
> that). Otherwise, it would abort and show a warning to the user that
> he's out of date.
The API supports exactly that. editor->open_file() accepts a base
revision parameter which is used to perform out-of-dateness checks.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Checkin without working copy
Posted by Joel Shellman <jo...@ikestrel.com>.
Ben Collins-Sussman wrote:
> Over the weekend, as a fun project, I started writing a C program called
> 'svnput'. It was a tiny program, designed to be run as 'svnput foo.c
> URL'. Under the hood, it would run:
>
> RA->get_latest_revnum()
> RA->open(parentURL)
> RA->get_commit_editor()
> editor->open_root(latest_revnum)
> editor->open_file(latest_revnum)
> send a txdelta against the empty stream
> editor->close_file()
> editor->close_edit()
>
> My thought is that this would address all the complaints out there about
> not being able to "upload" a single file without checking out an entire
> directory. We certainly have the API to accomplish this, after all.
>
> But in IRC, Erik Huelsmann and Greg Hudson convinced me that this was
> probably not a safe utility. While the semantics of subversion commits
> would prevent the user from overwriting the HEAD version of the file,
> there's still no guarantee that the user isn't blowing away somebody
> else's changes. For example,
>
> 1. svn cat -rHEAD URL > foo.c # fetches r12 of foo.c
> 2. edit foo.c
> 3. svnput foo.c URL # overwrites HEAD version of foo.c
Does svn cat show what revision you received?
If so, and if your little utility could also display the new revision
you created, then the user could see right there that oops, I smashed
someone's changes because it skipped a rev number.
Taking that a step further, your utility could accept a rev number on
the command line and check to make sure that it was creating the
successive rev number to the one given, (if the API supported that).
Otherwise, it would abort and show a warning to the user that he's out
of date.
-joel shellman
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Checkin without working copy
Posted by Dirk Hoffmann <dh...@web.de>.
Dirk Hoffmann wrote:
> Ben Collins-Sussman wrote:
>
>>
>> On Sep 27, 2004, at 7:45 AM, Dirk Hoffmann wrote:
>>
>>> Hi Ben,
>>>
>>> I'm extending the libsvn_client API by a svn_client_put()-function
>>> and find it quite difficult to deal with all those batons, pools
>>> etc.. I wrote 50 lines of code before coming to
>>> `editor->open_root(...)', just by copying&pasting from already
>>> existing code without fully understanding what I'm really coding.
>>>
>>> Would you please send me the sources of your `svnput'-tool just as
>>> an example. That would make my efforts a lot easier than they are at
>>> the moment.
>>>
>>
>> I committed it into Subversion weeks ago. It already works. Just
>> compile and go:
>>
>> http://svn.collab.net/repos/svn/trunk/tools/examples/svnput.c
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
>> For additional commands, e-mail: users-help@subversion.tigris.org
>>
>>
> Hm,
>
> for me it doesn't work as expected.
>
> First, the authentication dialog starts with asking for the password
> and continues with asking for the username and then the password again.
>
> Then it crashes with a Segmentation fault. I ran gdb on it and found
> that the crash occurred when I tried to execute the line
>
> err = editor->apply_textdelta (file_baton, NULL, pool,
> &handler, &handler_baton);
>
> I called svnput like so:
> ./svnput a_file http://dhoffmann:50080/packer/repos/test/a_file
>
> The root of the repo is http://dhoffmann:50080/packer/repos/test
>
> I'm sending mail messages to you and to the user list as well. Is that
> ok?
>
> Best regards
> Dirk
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
Hi Ben,
I did some debugging on the SIGSEGV.
The open_temp_file callback was missing in cbtable (which as far as I
learned from some comments will only be called when svn is accessed over
http)
This is what I added to make things work:
before the main function:
static svn_error_t *
my_open_tmp_file_callback (apr_file_t **fp,
void *callback_baton,
apr_pool_t *pool) {
const char* temp_dir;
const char* temp_file_prefix;
const char* temp_file_name;
SVN_ERR (svn_io_temp_dir (&temp_dir, pool));
temp_file_prefix = (const char*)svn_path_join (temp_dir, "svnput", pool);
SVN_ERR (svn_io_open_unique_file (fp, &temp_file_name,
temp_file_prefix, ".tmp", TRUE, pool));
return SVN_NO_ERROR;
}
inside the main function:
cbtable->open_tmp_file = my_open_tmp_file_callback;
There is still the authentication dialog problem.
Best regards
Dirk
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Checkin without working copy
Posted by Dirk Hoffmann <dh...@web.de>.
Ben Collins-Sussman wrote:
>
> On Sep 27, 2004, at 7:45 AM, Dirk Hoffmann wrote:
>
>> Hi Ben,
>>
>> I'm extending the libsvn_client API by a svn_client_put()-function
>> and find it quite difficult to deal with all those batons, pools
>> etc.. I wrote 50 lines of code before coming to
>> `editor->open_root(...)', just by copying&pasting from already
>> existing code without fully understanding what I'm really coding.
>>
>> Would you please send me the sources of your `svnput'-tool just as an
>> example. That would make my efforts a lot easier than they are at the
>> moment.
>>
>
> I committed it into Subversion weeks ago. It already works. Just
> compile and go:
>
> http://svn.collab.net/repos/svn/trunk/tools/examples/svnput.c
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
Hm,
for me it doesn't work as expected.
First, the authentication dialog starts with asking for the password and
continues with asking for the username and then the password again.
Then it crashes with a Segmentation fault. I ran gdb on it and found
that the crash occurred when I tried to execute the line
err = editor->apply_textdelta (file_baton, NULL, pool,
&handler, &handler_baton);
I called svnput like so:
./svnput a_file http://dhoffmann:50080/packer/repos/test/a_file
The root of the repo is http://dhoffmann:50080/packer/repos/test
I'm sending mail messages to you and to the user list as well. Is that ok?
Best regards
Dirk
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Checkin without working copy
Posted by Ben Collins-Sussman <su...@collab.net>.
On Sep 27, 2004, at 7:45 AM, Dirk Hoffmann wrote:
> Hi Ben,
>
> I'm extending the libsvn_client API by a svn_client_put()-function and
> find it quite difficult to deal with all those batons, pools etc.. I
> wrote 50 lines of code before coming to `editor->open_root(...)', just
> by copying&pasting from already existing code without fully
> understanding what I'm really coding.
>
> Would you please send me the sources of your `svnput'-tool just as an
> example. That would make my efforts a lot easier than they are at the
> moment.
>
I committed it into Subversion weeks ago. It already works. Just
compile and go:
http://svn.collab.net/repos/svn/trunk/tools/examples/svnput.c
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Checkin without working copy
Posted by Dirk Hoffmann <dh...@web.de>.
Hi Ben,
I'm extending the libsvn_client API by a svn_client_put()-function and
find it quite difficult to deal with all those batons, pools etc.. I
wrote 50 lines of code before coming to `editor->open_root(...)', just
by copying&pasting from already existing code without fully
understanding what I'm really coding.
Would you please send me the sources of your `svnput'-tool just as an
example. That would make my efforts a lot easier than they are at the
moment.
When I'm finished writing and testing my code maybe someone would like
to review it. You probably won't like to see it in subversion but it may
be provided as a patch or extra lib for those who need this special
functionallity and know what they're doing.
Best regards,
Dirk
Ben Collins-Sussman wrote:
>On Wed, 2004-09-01 at 01:47, Dirk Hoffmann wrote:
>
>
>
>>So I will definitely extend the javahl API to allow committing files
>>without needing a wc.
>>
>>
>
>Here's a little story.
>
>Over the weekend, as a fun project, I started writing a C program called
>'svnput'. It was a tiny program, designed to be run as 'svnput foo.c
>URL'. Under the hood, it would run:
>
> RA->get_latest_revnum()
> RA->open(parentURL)
> RA->get_commit_editor()
> editor->open_root(latest_revnum)
> editor->open_file(latest_revnum)
> send a txdelta against the empty stream
> editor->close_file()
> editor->close_edit()
>
>My thought is that this would address all the complaints out there about
>not being able to "upload" a single file without checking out an entire
>directory. We certainly have the API to accomplish this, after all.
>
>But in IRC, Erik Huelsmann and Greg Hudson convinced me that this was
>probably not a safe utility. While the semantics of subversion commits
>would prevent the user from overwriting the HEAD version of the file,
>there's still no guarantee that the user isn't blowing away somebody
>else's changes. For example,
>
> 1. svn cat -rHEAD URL > foo.c # fetches r12 of foo.c
> 2. edit foo.c
> 3. svnput foo.c URL # overwrites HEAD version of foo.c
>
>So what happens if somebody commits a new version (r13) of foo.c while
>the user is editing their local copy of r12? When they run 'svnput',
>they'll be unknowingly overwriting r13 with an edited copy of r12,
>effectively blowing away the r13 changes. (Sure, the r13 changes are
>still in the repository's history, but it may take a long while to
>discover that this mistake ever happened, and it's an annoying mess to
>fix.)
>
>This is why it's *so* much nicer to have a working copy. It prevents
>this sort of situation. When you commit from a working copy, the
>clients says "I'm uploading a new version of r12", and gets bounced out
>right away, rather than just overwriting whatever happens to be the
>latest version of the file. There's no way 'svnput' can know exactly
>what's being uploaded.
>
>So I think the better solution, in the long run, is to make libsvn_wc
>smarter, and come up with a way to have an .svn/entries file that only
>contains a single file, with all other siblings marked "unwanted", or
>somesuch.
>
>Anyway, I thought I'd communicate this wisdom to you, Dirk, before you
>write a java tool that does the same thing. Be wary.
>
>
>
>>Unforunately I haven't found much about how to utilize a commit editor.
>>Could you give me some pointers on this please.
>>
>>
>
>svn_delta.h. Go crazy. The comments in there are practically
>book-like, start around the comment, "Traversing Tree Deltas."
>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
>For additional commands, e-mail: users-help@subversion.tigris.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Checkin without working copy
Posted by Dirk Hoffmann <dh...@web.de>.
Ben Collins-Sussman wrote:
>On Wed, 2004-09-01 at 01:47, Dirk Hoffmann wrote:
>
>
>
>>So I will definitely extend the javahl API to allow committing files
>>without needing a wc.
>>
>>
>
>Here's a little story.
>
>Over the weekend, as a fun project, I started writing a C program called
>'svnput'. It was a tiny program, designed to be run as 'svnput foo.c
>URL'. Under the hood, it would run:
>
> RA->get_latest_revnum()
> RA->open(parentURL)
> RA->get_commit_editor()
> editor->open_root(latest_revnum)
> editor->open_file(latest_revnum)
> send a txdelta against the empty stream
> editor->close_file()
> editor->close_edit()
>
>My thought is that this would address all the complaints out there about
>not being able to "upload" a single file without checking out an entire
>directory. We certainly have the API to accomplish this, after all.
>
>But in IRC, Erik Huelsmann and Greg Hudson convinced me that this was
>probably not a safe utility. While the semantics of subversion commits
>would prevent the user from overwriting the HEAD version of the file,
>there's still no guarantee that the user isn't blowing away somebody
>else's changes. For example,
>
> 1. svn cat -rHEAD URL > foo.c # fetches r12 of foo.c
> 2. edit foo.c
> 3. svnput foo.c URL # overwrites HEAD version of foo.c
>
>So what happens if somebody commits a new version (r13) of foo.c while
>the user is editing their local copy of r12? When they run 'svnput',
>they'll be unknowingly overwriting r13 with an edited copy of r12,
>effectively blowing away the r13 changes. (Sure, the r13 changes are
>still in the repository's history, but it may take a long while to
>discover that this mistake ever happened, and it's an annoying mess to
>fix.)
>
>This is why it's *so* much nicer to have a working copy. It prevents
>this sort of situation. When you commit from a working copy, the
>clients says "I'm uploading a new version of r12", and gets bounced out
>right away, rather than just overwriting whatever happens to be the
>latest version of the file. There's no way 'svnput' can know exactly
>what's being uploaded.
>
>So I think the better solution, in the long run, is to make libsvn_wc
>smarter, and come up with a way to have an .svn/entries file that only
>contains a single file, with all other siblings marked "unwanted", or
>somesuch.
>
>Anyway, I thought I'd communicate this wisdom to you, Dirk, before you
>write a java tool that does the same thing. Be wary.
>
>
>
>>Unforunately I haven't found much about how to utilize a commit editor.
>>Could you give me some pointers on this please.
>>
>>
>
>svn_delta.h. Go crazy. The comments in there are practically
>book-like, start around the comment, "Traversing Tree Deltas."
>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
>For additional commands, e-mail: users-help@subversion.tigris.org
>
>
>
>
Ok, I believe I understand the problem: Without a wc there is no way for
whatever sort of client to know which revision the local copy
represents. I'll keep that in my mind.
Thanks a lot for pointing that out.
In my use case it's probably not going to be a problem, since users only
checkin files. The software-system I'm developing is the only part
performing checkouts and those are not returned to the users.
Best Regards,
Dirk
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Checkin without working copy
Posted by Ben Collins-Sussman <su...@collab.net>.
On Wed, 2004-09-01 at 01:47, Dirk Hoffmann wrote:
> So I will definitely extend the javahl API to allow committing files
> without needing a wc.
Here's a little story.
Over the weekend, as a fun project, I started writing a C program called
'svnput'. It was a tiny program, designed to be run as 'svnput foo.c
URL'. Under the hood, it would run:
RA->get_latest_revnum()
RA->open(parentURL)
RA->get_commit_editor()
editor->open_root(latest_revnum)
editor->open_file(latest_revnum)
send a txdelta against the empty stream
editor->close_file()
editor->close_edit()
My thought is that this would address all the complaints out there about
not being able to "upload" a single file without checking out an entire
directory. We certainly have the API to accomplish this, after all.
But in IRC, Erik Huelsmann and Greg Hudson convinced me that this was
probably not a safe utility. While the semantics of subversion commits
would prevent the user from overwriting the HEAD version of the file,
there's still no guarantee that the user isn't blowing away somebody
else's changes. For example,
1. svn cat -rHEAD URL > foo.c # fetches r12 of foo.c
2. edit foo.c
3. svnput foo.c URL # overwrites HEAD version of foo.c
So what happens if somebody commits a new version (r13) of foo.c while
the user is editing their local copy of r12? When they run 'svnput',
they'll be unknowingly overwriting r13 with an edited copy of r12,
effectively blowing away the r13 changes. (Sure, the r13 changes are
still in the repository's history, but it may take a long while to
discover that this mistake ever happened, and it's an annoying mess to
fix.)
This is why it's *so* much nicer to have a working copy. It prevents
this sort of situation. When you commit from a working copy, the
clients says "I'm uploading a new version of r12", and gets bounced out
right away, rather than just overwriting whatever happens to be the
latest version of the file. There's no way 'svnput' can know exactly
what's being uploaded.
So I think the better solution, in the long run, is to make libsvn_wc
smarter, and come up with a way to have an .svn/entries file that only
contains a single file, with all other siblings marked "unwanted", or
somesuch.
Anyway, I thought I'd communicate this wisdom to you, Dirk, before you
write a java tool that does the same thing. Be wary.
>
> Unforunately I haven't found much about how to utilize a commit editor.
> Could you give me some pointers on this please.
svn_delta.h. Go crazy. The comments in there are practically
book-like, start around the comment, "Traversing Tree Deltas."
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org