You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by plasma <pl...@pchome.com.tw> on 2003/05/17 01:10:31 UTC
patch to libsvn_client/export.c
hi all,
'svn export' refuses to export source files into an existing
directory. Say, if I ran a 'svn export URL PATH', found I made a
mistake (maybe forget to commit a file, or export a wrong branch),
then rerun 'svn export URL2 PATH'. Because the PATH was created by
previous command, the second one will refuse to run. PATH should be
removed explicity by user, and I think it's annoying.
The following patch will make svn exports source files into an
existing directory. It only barks if the existing target is a file,
instead of a directory.
plasma
LOG:
Make svn exports source files into an existing directory.
PATCH:
--- subversion/libsvn_client/export.c.orig Sat May 10 09:05:54 2003
+++ subversion/libsvn_client/export.c Fri May 16 23:35:10 2003
@@ -305,11 +305,12 @@
svn_node_kind_t kind;
SVN_ERR (svn_io_check_path (eb->root_path, &kind, pool));
- if (kind != svn_node_none)
+ if (kind == svn_node_none)
+ SVN_ERR (svn_io_dir_make (eb->root_path, APR_OS_DEFAULT, pool));
+ else if (kind == svn_node_file)
return svn_error_create (SVN_ERR_WC_OBSTRUCTED_UPDATE,
NULL, eb->root_path);
- SVN_ERR (svn_io_dir_make (eb->root_path, APR_OS_DEFAULT, pool));
if (eb->notify_func)
(*eb->notify_func) (eb->notify_baton,
@@ -338,8 +339,14 @@
struct edit_baton *eb = parent_baton;
const char *full_path = svn_path_join (eb->root_path,
path, pool);
+ svn_node_kind_t kind;
- SVN_ERR (svn_io_dir_make (full_path, APR_OS_DEFAULT, pool));
+ SVN_ERR (svn_io_check_path (full_path, &kind, pool));
+ if (kind == svn_node_none)
+ SVN_ERR (svn_io_dir_make (full_path, APR_OS_DEFAULT, pool));
+ else if (kind == svn_node_file)
+ return svn_error_create (SVN_ERR_WC_OBSTRUCTED_UPDATE,
+ NULL, eb->root_path);
if (eb->notify_func)
(*eb->notify_func) (eb->notify_baton,
==========================================================
���h�e���u�]�p�v�w ���Q��.���p�A�̷s�O�@
http://edm-prg.epaper.com.tw/click.php?ad_code=7746
==========================================================
PChome�ʪ��G�x�W�Ĥ@���ʪ������I
http://shopping.pchome.com.tw/
==========================================================
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Wish List for Subversion
Posted by Ben Collins-Sussman <su...@collab.net>.
"Tom Browder" <TB...@cox.net> writes:
> 1. Use the rtag command to label snapshots in the development cycle with
> long tags that tell what the snapshot means, e.g.,
> "v16may2003_draft_to_customer."
$ svn copy http://host/project/trunk \
http://host/project/tags/v16may2003_draft_to_customer
>
> 2. Use the history command like so:
>
> cvs history -T | fgrep <module name>
>
> to see tags in date order.
$ svn ls http://host/project/tags
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Wish List for Subversion
Posted by ryan <ry...@netidea.com>.
Hi,
Curious - how many reversion control systems have you used?
The only reason why tags are really necessary in CVS is because there is no
atomic changesets. In CVS its impossible to check out your files to a
consistent set unless you tag them.
In SVN that is not necessary since any given change number should
technically compile fine (if people don¹t check in broken build). Project
management can map releases versions to releases to customer.
Another option is using the cheap branch faculity of SVN... Every time you
have an external release you create a new branch in /tags (or whereever...)
with a name like "v16may2003_draft_to_customer". You then have the
advantage of having a real branch. So you can patch and customize for the
customer on their release branch, and integrate it back to your mainline if
necessary.
Hope this helps.
Regards,
-ryan
On 5/17/03 9:25 AM, "Tom Browder" <TB...@cox.net> wrote:
> At the risk of getting shot, I would like to put in a plug for tags as in
> CVS. I have read the subversion book fairly closely and don't understand the
> rationale for treating a tag like a branch. As a lightweight CVS user, I
> appreciate being able to:
>
> 1. Use the rtag command to label snapshots in the development cycle with
> long tags that tell what the snapshot means, e.g.,
> "v16may2003_draft_to_customer."
>
> 2. Use the history command like so:
>
> cvs history -T | fgrep <module name>
>
> to see tags in date order.
>
> I also like the use of the environment variable CVSROOT to let cvs know the
> location of the repository. I think that would be very useful for
> subversion so one wouldn't have to enter the repository name, just the
> subdirectory of interest (whether remote or local).
>
> I'm ready to start trying subversion now that someone found the Berkeley DB
> problem with Rh 9. I look forward to what I see as the most valuable
> capabilities of subversion for my typical use:
>
> + ability to version binary files without completely duplicating the whole
> file with each change
>
> + ability to truly version the module tree structure
>
> + local change history (and revert capability) to aid development while on
> the road
>
> + ability to convert the working directory (or specific files) in place to
> a previous revision
>
> Thanks to all the subversion developers--this project has been sorely
> needed!
>
> Tom Browder
> SRS Technologies, Inc.
> Fort Walton Beach, Florida
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Wish List for Subversion
Posted by Tom Browder <TB...@cox.net>.
At the risk of getting shot, I would like to put in a plug for tags as in
CVS. I have read the subversion book fairly closely and don't understand the
rationale for treating a tag like a branch. As a lightweight CVS user, I
appreciate being able to:
1. Use the rtag command to label snapshots in the development cycle with
long tags that tell what the snapshot means, e.g.,
"v16may2003_draft_to_customer."
2. Use the history command like so:
cvs history -T | fgrep <module name>
to see tags in date order.
I also like the use of the environment variable CVSROOT to let cvs know the
location of the repository. I think that would be very useful for
subversion so one wouldn't have to enter the repository name, just the
subdirectory of interest (whether remote or local).
I'm ready to start trying subversion now that someone found the Berkeley DB
problem with Rh 9. I look forward to what I see as the most valuable
capabilities of subversion for my typical use:
+ ability to version binary files without completely duplicating the whole
file with each change
+ ability to truly version the module tree structure
+ local change history (and revert capability) to aid development while on
the road
+ ability to convert the working directory (or specific files) in place to
a previous revision
Thanks to all the subversion developers--this project has been sorely
needed!
Tom Browder
SRS Technologies, Inc.
Fort Walton Beach, Florida
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: patch to libsvn_client/export.c
Posted by Philip Martin <ph...@codematters.co.uk>.
plasma <pl...@pchome.com.tw> writes:
> LOG:
>
> Issue #1296. Add a new --force option to 'svn export'.
Please read the HACKING file or run
'svn log http://svn.collab.net/repos/svn'
to see the preferred format for log messages,
> --- subversion/libsvn_client/export.c.orig Sat May 10 09:05:54 2003
> +++ subversion/libsvn_client/export.c Sun May 18 14:00:09 2003
[...]
> @@ -305,11 +307,22 @@
> svn_node_kind_t kind;
>
> SVN_ERR (svn_io_check_path (eb->root_path, &kind, pool));
> - if (kind != svn_node_none)
> - return svn_error_create (SVN_ERR_WC_OBSTRUCTED_UPDATE,
> - NULL, eb->root_path);
> + if (eb->force)
> + {
> + if (kind == svn_node_none)
> + SVN_ERR (svn_io_dir_make (eb->root_path, APR_OS_DEFAULT, pool));
> + else if (kind == svn_node_file)
> + return svn_error_create (SVN_ERR_WC_OBSTRUCTED_UPDATE,
> + NULL, eb->root_path);
> + }
> + else
> + {
> + if (kind != svn_node_none)
> + return svn_error_create (SVN_ERR_WC_OBSTRUCTED_UPDATE,
> + NULL, eb->root_path);
> + SVN_ERR (svn_io_dir_make (eb->root_path, APR_OS_DEFAULT, pool));
> + }
Too much code, I'd prefer something like
if (kind == svn_node_none)
SVN_ERR (svn_io_dir_make ( ... ));
else if (! (kind == svn_node_dir && force))
return svn_error_create ( ... );
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: patch to libsvn_client/export.c
Posted by plasma <pl...@pchome.com.tw>.
On Sat, May 17, 2003 at 11:20:47AM -0500, cmpilato@collab.net wrote:
> William Uther <wi...@cse.unsw.edu.au> writes:
> > On Saturday, May 17, 2003, at 09:58 PM, plasma wrote:
> > > On Fri, May 16, 2003 at 11:26:41PM -0500, cmpilato@collab.net wrote:
> > > Since the patch is here, if you core members find it acceptable, maybe
> > > you would like to add a new option to complete this issue? I would be
> > > appreciate since I prefer 'svn export' do things this way.
> >
> > This sounds like a job for --force.
>
> Sound good to me.
I just found my previous patch got something wrong. But seems it
never reached dev mailing list, I'm composing a new email.
This is a patch to add a --force option to 'svn export'. Because I'm
a novice at C programming, please don't laugh if anything stupid is
made.
plasma
LOG:
Issue #1296. Add a new --force option to 'svn export'.
PATCH:
--- subversion/clients/cmdline/main.c.orig Sat May 10 09:02:58 2003
+++ subversion/clients/cmdline/main.c Sun May 18 00:49:40 2003
@@ -226,7 +226,7 @@
" 2. Exports a clean directory tree from the working copy specified by\n"
" PATH1 into PATH2. all local changes will be preserved, but files\n"
" not under revision control will not be copied.\n",
- {'r', 'q', SVN_CL__AUTH_OPTIONS} },
+ {'r', 'q', svn_cl__force_opt, SVN_CL__AUTH_OPTIONS} },
{ "help", svn_cl__help, {"?", "h"},
"Display this usage message.\n"
--- subversion/clients/cmdline/export-cmd.c.orig Sat May 10 09:03:00 2003
+++ subversion/clients/cmdline/export-cmd.c Sun May 18 00:51:56 2003
@@ -71,6 +71,7 @@
SVN_ERR (svn_client_export (from,
to,
&(opt_state->start_revision),
+ opt_state->force,
ctx,
pool));
return SVN_NO_ERROR;
--- subversion/include/svn_client.h.orig Sun May 18 00:43:58 2003
+++ subversion/include/svn_client.h Sun May 18 00:44:18 2003
@@ -1186,6 +1186,7 @@
svn_client_export (const char *from,
const char *to,
svn_opt_revision_t *revision,
+ svn_boolean_t force,
svn_client_ctx_t *ctx,
apr_pool_t *pool);
--- subversion/libsvn_client/export.c.orig Sat May 10 09:05:54 2003
+++ subversion/libsvn_client/export.c Sun May 18 14:00:09 2003
@@ -140,6 +140,7 @@
svn_client_export (const char *from,
const char *to,
svn_opt_revision_t *revision,
+ svn_boolean_t force,
svn_client_ctx_t *ctx,
apr_pool_t *pool)
{
@@ -155,7 +156,7 @@
URL = svn_path_canonicalize (from, pool);
SVN_ERR (svn_client__get_export_editor (&export_editor, &edit_baton,
- to, URL, ctx, pool));
+ to, URL, force, ctx, pool));
if (revision->kind == svn_opt_revision_number)
revnum = revision->value.number;
@@ -194,6 +195,7 @@
{
const char *root_path;
const char *root_url;
+ svn_boolean_t force;
svn_wc_notify_func_t notify_func;
void *notify_baton;
@@ -305,11 +307,22 @@
svn_node_kind_t kind;
SVN_ERR (svn_io_check_path (eb->root_path, &kind, pool));
- if (kind != svn_node_none)
- return svn_error_create (SVN_ERR_WC_OBSTRUCTED_UPDATE,
- NULL, eb->root_path);
+ if (eb->force)
+ {
+ if (kind == svn_node_none)
+ SVN_ERR (svn_io_dir_make (eb->root_path, APR_OS_DEFAULT, pool));
+ else if (kind == svn_node_file)
+ return svn_error_create (SVN_ERR_WC_OBSTRUCTED_UPDATE,
+ NULL, eb->root_path);
+ }
+ else
+ {
+ if (kind != svn_node_none)
+ return svn_error_create (SVN_ERR_WC_OBSTRUCTED_UPDATE,
+ NULL, eb->root_path);
+ SVN_ERR (svn_io_dir_make (eb->root_path, APR_OS_DEFAULT, pool));
+ }
- SVN_ERR (svn_io_dir_make (eb->root_path, APR_OS_DEFAULT, pool));
if (eb->notify_func)
(*eb->notify_func) (eb->notify_baton,
@@ -338,8 +351,21 @@
struct edit_baton *eb = parent_baton;
const char *full_path = svn_path_join (eb->root_path,
path, pool);
+ svn_node_kind_t kind;
- SVN_ERR (svn_io_dir_make (full_path, APR_OS_DEFAULT, pool));
+ if (eb->force)
+ {
+ SVN_ERR (svn_io_check_path (full_path, &kind, pool));
+ if (kind == svn_node_none)
+ SVN_ERR (svn_io_dir_make (full_path, APR_OS_DEFAULT, pool));
+ else if (kind == svn_node_file)
+ return svn_error_create (SVN_ERR_WC_OBSTRUCTED_UPDATE,
+ NULL, eb->root_path);
+ }
+ else
+ {
+ SVN_ERR (svn_io_dir_make (full_path, APR_OS_DEFAULT, pool));
+ }
if (eb->notify_func)
(*eb->notify_func) (eb->notify_baton,
@@ -545,6 +571,7 @@
void **edit_baton,
const char *root_path,
const char *root_url,
+ svn_boolean_t force,
svn_client_ctx_t *ctx,
apr_pool_t *pool)
{
@@ -553,6 +580,7 @@
eb->root_path = apr_pstrdup (pool, root_path);
eb->root_url = apr_pstrdup (pool, root_url);
+ eb->force = force;
eb->notify_func = ctx->notify_func;
eb->notify_baton = ctx->notify_baton;
==========================================================
New Galant�R���O�Ʋ���o�j��
http://edm-prg.epaper.com.tw/click.php?ad_code=7745
==========================================================
PChome�ʪ��G�x�W�Ĥ@���ʪ������I
http://shopping.pchome.com.tw/
==========================================================
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: patch to libsvn_client/export.c
Posted by cm...@collab.net.
William Uther <wi...@cse.unsw.edu.au> writes:
> On Saturday, May 17, 2003, at 09:58 PM, plasma wrote:
>
> > On Fri, May 16, 2003 at 11:26:41PM -0500, cmpilato@collab.net wrote:
> >> plasma <pl...@pchome.com.tw> writes:
> >>
> >>> hi all,
> >>>
> >>> 'svn export' refuses to export source files into an existing
> >>> directory. Say, if I ran a 'svn export URL PATH', found I made a
> >>> mistake (maybe forget to commit a file, or export a wrong branch),
> >>> then rerun 'svn export URL2 PATH'. Because the PATH was created by
> >>> previous command, the second one will refuse to run. PATH should be
> >>> removed explicity by user, and I think it's annoying.
> >>
> >> I'm confused. If you started an export and then cancelled it because
> >> it was the wrong thing, why would you want your next export to
> >> effectively interleave its output with whatever cruft you now have on
> >> disk from your failed export?!
>
> There are other uses aside from this one. The others are not so
> horribly broken. I see it as analogous to untarring over an already
> existing dir. Not the common case, but sometimes useful.
Okay, I'm down with that.
> > Since the patch is here, if you core members find it acceptable, maybe
> > you would like to add a new option to complete this issue? I would be
> > appreciate since I prefer 'svn export' do things this way.
>
> This sounds like a job for --force.
Sound good to me.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: patch to libsvn_client/export.c
Posted by William Uther <wi...@cse.unsw.edu.au>.
On Saturday, May 17, 2003, at 09:58 PM, plasma wrote:
> On Fri, May 16, 2003 at 11:26:41PM -0500, cmpilato@collab.net wrote:
>> plasma <pl...@pchome.com.tw> writes:
>>
>>> hi all,
>>>
>>> 'svn export' refuses to export source files into an existing
>>> directory. Say, if I ran a 'svn export URL PATH', found I made a
>>> mistake (maybe forget to commit a file, or export a wrong branch),
>>> then rerun 'svn export URL2 PATH'. Because the PATH was created by
>>> previous command, the second one will refuse to run. PATH should be
>>> removed explicity by user, and I think it's annoying.
>>
>> I'm confused. If you started an export and then cancelled it because
>> it was the wrong thing, why would you want your next export to
>> effectively interleave its output with whatever cruft you now have on
>> disk from your failed export?!
There are other uses aside from this one. The others are not so
horribly broken. I see it as analogous to untarring over an already
existing dir. Not the common case, but sometimes useful.
> Generally, there is not necessarily many differences between branches
> or revisions. Maybe files remain the same, just theirs contents
> differ.
Ugh - that's a horrible argument.
> Since the patch is here, if you core members find it acceptable, maybe
> you would like to add a new option to complete this issue? I would be
> appreciate since I prefer 'svn export' do things this way.
This sounds like a job for --force.
Will :-}
--
Dr William Uther National ICT Australia
Phone: +61 2 9385 6926 School of Computer Science and
Engineering
Email: willu@cse.unsw.edu.au University of New South Wales
Jabber: willu@jabber.cse.unsw.edu.au Sydney, Australia
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: patch to libsvn_client/export.c
Posted by plasma <pl...@pchome.com.tw>.
On Fri, May 16, 2003 at 11:26:41PM -0500, cmpilato@collab.net wrote:
> plasma <pl...@pchome.com.tw> writes:
>
> > hi all,
> >
> > 'svn export' refuses to export source files into an existing
> > directory. Say, if I ran a 'svn export URL PATH', found I made a
> > mistake (maybe forget to commit a file, or export a wrong branch),
> > then rerun 'svn export URL2 PATH'. Because the PATH was created by
> > previous command, the second one will refuse to run. PATH should be
> > removed explicity by user, and I think it's annoying.
>
> I'm confused. If you started an export and then cancelled it because
> it was the wrong thing, why would you want your next export to
> effectively interleave its output with whatever cruft you now have on
> disk from your failed export?!
Generally, there is not necessarily many differences between branches
or revisions. Maybe files remain the same, just theirs contents
differ.
I made this patch because someone (sorry, I forgot who) motivated me
to do so on #svn long time ago. He mentioned about an issue about
it. I found issue #1296 might be the one just now.
Since the patch is here, if you core members find it acceptable, maybe
you would like to add a new option to complete this issue? I would be
appreciate since I prefer 'svn export' do things this way.
plasma
==========================================================
���h�e���u�]�p�v�w ���Q��.���p�A�̷s�O�@
http://edm-prg.epaper.com.tw/click.php?ad_code=7746
==========================================================
PChome�ʪ��G�x�W�Ĥ@���ʪ������I
http://shopping.pchome.com.tw/
==========================================================
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: patch to libsvn_client/export.c
Posted by cm...@collab.net.
plasma <pl...@pchome.com.tw> writes:
> hi all,
>
> 'svn export' refuses to export source files into an existing
> directory. Say, if I ran a 'svn export URL PATH', found I made a
> mistake (maybe forget to commit a file, or export a wrong branch),
> then rerun 'svn export URL2 PATH'. Because the PATH was created by
> previous command, the second one will refuse to run. PATH should be
> removed explicity by user, and I think it's annoying.
I'm confused. If you started an export and then cancelled it because
it was the wrong thing, why would you want your next export to
effectively interleave its output with whatever cruft you now have on
disk from your failed export?!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org