Stefan.Fuhrmann@etas.de wrote:
> Hello dev,
>
> we are using externals to fetch required projects automatically.
> Imagine, we got 2 projects, p1 and p2, with p2 depending on p1:
>
> C:\develop>svn propget svn:externals p2
> ..\p1 file:///C:/temp/t/p1/trunk
>
> That is, p1 and p2 are "sibbling" folders in the working copy.
> Note, C:\develop is not a working copy itself.
>
> Changes to p1 and p2 are listed in both, svn st and the TSVN
> commit dialog. However, only changes to p2 get actually
> commited (TSVN and SVN are consitent here).
Are p1 and p2 pointing to the same repository? Or are they from
different repositories?
If they're from the same repository, then you _could_ commit changes in
both with one commit.
But if they're from different repos, then TSVN should show you a warning
dialog and _not_ show the changes inside the externals dir.
> That behavior is relatively new. I think, recent changes in SVN
> caused the c/i traversal to stop on folders "outside" the working
> copy.
Don't know about that. But I'll check the changelogs as soon as I've got
some more time.
> Although this is primarily a problem with the SVN libs themselves,
> TSVN should try to work around that inconsitency between
> commit dialog status display and actual commit. Guess my favorite
> solution .. ;)
I guess you're thinking about a TSVN workaround, most likely because I'm
usually faster doing things ;)
But you can do the workaround yourself: just uncheck at least one file
from being committed, then TSVN will do a non-recursive commit and
therefore commit the externals too (_if_ they're from the same repo).
> Hope that doesn't turn out to be overly complicated.
Not complicated, but almost impossible. Sorry.
Sure, there may be ways to really work around this, but this would
require non-recursive commits which TSVN already does if not all items
shown in the commit dialog are to be committed. But non-recursive
commits can cause problems with Subversion, especially if you try a
non-recursive commit on deleted/moved/renamed folders...
So a workaround would work in some situations, but break in others. Now
guess what I'm (not) doing? ;)
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Tue Aug 3 08:10:14 2004