[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PATCH] copy file to existing directory.

From: Stefan Sperling <stsp_at_elego.de>
Date: Wed, 13 Aug 2008 23:08:04 +0200

On Thu, Aug 14, 2008 at 02:07:13AM +0800, Rui, Guo wrote:
> On Wed, Aug 13, 2008 at 12:55:09PM +0200, Stefan Sperling wrote:
> > Did I explain the problem correctly?
> >
> Yep! You've got the whole story.

OK, that makes me happy :)

> > Looking at the log messages on your branch, it seems you have done
> > most of the hidden directory implementation in the working copy library.
> >
> > However, these changes are both made in the client library, and
> > therefore make it aware of "hidden" directories. Do we really want
> > the client library to know about "hidden" directories?
> Well the word 'hidden' just comes from the parameter show_hidden in
> svn_wc_entry() series of functions (There are three of them, if I remember
> correctly). Originally, the parameter show_hidden includes two kinds of
> entries: deleted and absent. And now, in my branch, the excluded entry is also
> considered hidden.

Ah, OK. I just used 'hidden' directory to mean the functionality
you are implementing on your branch. I am not used to the terminology
around sparse checkouts.

You need a damn dictionary for every feature in Subversion, really.
I bet you could put 3 Subversion developers in a single room.
One working on tree conflicts, one working on merge-tracking,
and one working on sparse checkouts. None of them would understand
what the other two were talking about.

> > But if the client library is already aware of hidden directories
> > on your branch, then it's fine to put this check there, too.
>
> What I can say is that the client should have the concept of 'excluded'
> directory, just as the know something about deleted and absent now. I think
> the check here does not make use of any internal detail that the client should
> not know. Or have I lost the position to make a fair judgment? :-)

I'd say you are the one to judge where it makes sense to put it.
I simply don't know whether libsvn_client is supposed to know
about this feature or not.

> > But more importantly, since the working copy corruption problem
> > is fixed with the change to copy_file_administratively, I think
> > we should only apply that fix to trunk. Making Subversion report
> > more useful error messages in case directories are missing/hidden
> > can be done on your branch.
> >
> > Do you agree?
> I think this is not specific to my branch, even though it will benefit the
> most. So, if you think it should go into my branch first, I'll be OK. But
> personally I still believe it can go into trunk.

> But (there will always be a but :-)), consistent error report is really a
> serious requirement.

Yes, I think so, too.

It can be done on trunk as well if you want.

The most important thing for me is that whoever fixes this, on
whatever branch, should make sure that all cases are consistent.
That's why I made the scripts.

> The most typical error report till now will fall back to
> the default 'Entry XXX is already under version control.' I know that is far
> from perfect, but it will be really painful to check each of this report and
> provide a better one for hidden entries. I even begin to doubt that whether I
> should use the default 'under version control' message in my patch.

One argument for doing this in your branch is that we'll probably
want the messages to change anyway when your branch is merged into
trunk. I mean, we probably want the messages to tell the user that
the problem might be that the directory is hidden (or excluded,
or whatever you call that). We can't make the messages say this
on trunk now because the feature does not yet exist there.

> Whatever message I use, your scripts are of great value. I'll check if the
> current state of the error report is satisfactory. But I may not be able to
> further improve the error report within the following days -- The final
> deadline of the gsoc is approaching.

That's OK. It does not need to be done quickly. You should do
more important things first, of course!

> PS: I'm going to go offline next week (visting Stanford), I think I have to
> hurry up. What a busy summer 'vacation'!

Sounds like you're having fun though, even though you're busy :)

> > Note that the scripts run the final svn command in gdb.
> > If you're not familiar with gdb: You just need to type
> > run
> > and press enter to run the svn command from within gdb.
> > You should learn about gdb if you don't know it yet, it's nice :)
> Yes, I do use gdb. It's very powerful, but not very handy. Do you use any
> front end such as ddd or insight?

No. I tried ddd a little a long time ago and I liked the cute
boxes it can draw with variables in them etc. But I tend to use
the command line interface anyway because it gets in the way
much less than a GUI and is a bit quicker to use. I don't use any
fancy features so it suits me even from a usability point of view.
Hint: If you need a fancy display of the code when using gdb,
try 'gdb -tui'.

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-08-13 23:07:42 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.