TortoiseSVN Merge Behavior with svn:externals

[Ryan Phillips]

Hi All,

It took me awhile, but I was able to switch my employer over to
subversion. We are mostly a Linux shop, but I have ran into a slight
discrepancy.

The command line svn tool doesn't recurse into svn:externals on an svn
merge. Everything is running SVN 1.5 and TortoiseSVN 1.5. We have the
typical repository layout with a trunk/ and branches/feature_1 folder.
When syncing the branch on Linux with svn merge everything works fine.
The externals directory modifications are _not_ part of the commit.
However, if a developer does a TortoiseSVN merge from the trunk to the
feature branch then modifications within the externals are picked up
into the merge commit.

According to the documentation for TortoiseSVN recursing into the
subdirectories is expected; however, the SVN red-bean book says that
the svn tools do not recurse except for 4 commands (checkout, status,
update, and one more). I've been using the cli for a long time. Is
committing a "merge" with Tortoise ok with svn:external modifications?
and does the merge tracking still work?

Thanks,
Ryan

---------------------------------------------------------------------
To unsubscribe, e-mail: users-un...@tortoisesvn.tigris.org
For additional commands, e-mail: users...@tortoisesvn.tigris.org

[Stefan Küng]

Ryan Phillips wrote:
> Hi All,
>
> It took me awhile, but I was able to switch my employer over to
> subversion. We are mostly a Linux shop, but I have ran into a slight
> discrepancy.
>
> The command line svn tool doesn't recurse into svn:externals on an svn
> merge. Everything is running SVN 1.5 and TortoiseSVN 1.5. We have the
> typical repository layout with a trunk/ and branches/feature_1 folder.
> When syncing the branch on Linux with svn merge everything works fine.
> The externals directory modifications are _not_ part of the commit.
> However, if a developer does a TortoiseSVN merge from the trunk to the
> feature branch then modifications within the externals are picked up
> into the merge commit.
>
> According to the documentation for TortoiseSVN recursing into the
> subdirectories is expected; however, the SVN red-bean book says that
> the svn tools do not recurse except for 4 commands (checkout, status,
> update, and one more). I've been using the cli for a long time. Is
> committing a "merge" with Tortoise ok with svn:external modifications?
> and does the merge tracking still work?

Are you sure that the *merge* also included the externals? I seriously
doubt that, because as you said Subversion does not do that, and TSVN
uses the Subversion library to do the merge.
Please check again, maybe some other operation made modifications to the
externals.

Stefan

--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net

[Ryan Phillips]

Hi Stefan,

Thanks for replying.

I believe I was a little unclear. The TortoiseSVN merge did not bring
in merges into the external. The external had local working copy
modifications. After the merge, and upon the commit of the merge the
external was included within the commit set, since TortoiseSVN
defaults to including all externals in a commit. One has to unselect
the files in the external manually from what I can tell.

-Ryan

[Stefan Küng]

Yes, that is a feature that was requested often: if the externals are
from the same repository, then the commit will include them by default.
Only if the externals are from a different repository (i.e., they have a
different repository uuid), then the commit dialog won't show them.

[Gabriel]

Hi,

Have a look at: http://groups.google.com/group/tortoisesvn/browse_thread/thread/4784f6ee042328f5?lnk=igtc

It's about the same thing, I asked for it in the TortoiseGroup and
this described the behaviour, which would explain why VisualSVN
wouldn't support it.

Cheers,
Gab

On 14 aug, 19:26, Stefan Küng <tortoise...@gmail.com> wrote:
> Ryan Phillips wrote:

>  signature.asc
> < 1KViewDownload

[Ryan Phillips]

On Fri, Aug 15, 2008 at 7:17 AM, Gabriel <gabri...@gmail.com> wrote:
> Hi,
>
> Have a look at: http://groups.google.com/group/tortoisesvn/browse_thread/thread/4784f6ee042328f5?lnk=igtc
>
> It's about the same thing, I asked for it in the TortoiseGroup and
> this described the behaviour, which would explain why VisualSVN
> wouldn't support it.
>

Interesting... I don't use Tortoise everyday, so the decision to
recursively commit the externals doesn't directly impact me. However,
the behavior is different than how the SVN command line clients work.
Personally, I believe it should be optional. Initially I thought this
behavior might have a problem with revision numbers and merges, but
after some more though, I can't come up with scenario that a merge
would fail.

-Ryan

[Silver Zachara]

Hi developers,

I really need help, when I merged from trunk to the branch I has
conflict in one file, so I clicked "Resolved conflict". I wanted to take
a look how are colors set in TortoiseMerge(View - Setting - and tab
Colors). And now a problem, in this dialog I clicked "OK" and all colors
have changed in TortoiseMerge(I didn't edit any color!!!). How can I
switch back to default colors(I have accustomed this default colors).
I have tried uninstall and deleted all TortoiseSVN folders in Document
and Settings in Application Data and reinstall, but the colors are still
same.
What I need to do, so as the colors revert to default state ?

Thank for reactions.

--
-------------------------------------------------------------------
--== Silver Zachara ==--
- pgp - http://radeonvmod.ic.cz/keys/silver....@gmail.com.asc -

[Stefan Küng]

Silver Zachara wrote:
> Hi developers,
>
> I really need help, when I merged from trunk to the branch I has
> conflict in one file, so I clicked "Resolved conflict". I wanted to take
> a look how are colors set in TortoiseMerge(View - Setting - and tab
> Colors). And now a problem, in this dialog I clicked "OK" and all colors
> have changed in TortoiseMerge(I didn't edit any color!!!). How can I
> switch back to default colors(I have accustomed this default colors).
> I have tried uninstall and deleted all TortoiseSVN folders in Document
> and Settings in Application Data and reinstall, but the colors are still
> same.
> What I need to do, so as the colors revert to default state ?

Delete the registry key
HKCU\Software\TortoiseMerge\Colors

[Silver Zachara]

Stefan Küng napsal(a):

Silver Zachara wrote:
  

Hi developers,

I really need help, when I merged from trunk to the branch I has
conflict in one file, so I clicked "Resolved conflict". I wanted to take
a look how are colors set in TortoiseMerge(View - Setting - and tab
Colors). And now a problem, in this dialog I clicked "OK" and all colors
have changed in TortoiseMerge(I didn't edit any color!!!). How can I
switch back to default colors(I have accustomed this default colors).
I have tried uninstall and deleted all TortoiseSVN folders in Document
and Settings in Application Data and reinstall, but the colors are still
same.
What I need to do, so as the colors revert to default state ?
    

Delete the registry key
HKCU\Software\TortoiseMerge\Colors

Stefan

  

Thank you it works ;)

[dm3281]

I'm new to SVN and Totorise and thought I'd begin using it for source coding
my Visual Studio 6, 2003, 2005, and 2008 projects.

I'm just wondering what is the best way for me to do this. I.E., do I
create a Solution folder for my project, then create "trunk", "tags",
"branch" folders? If so, I suppose I put my individual projects for the
solutions under th solution folder?

If I don't have a solution and simply have a project, do I create a project
folder, then under this have "trunk", "tags", and "branch" and then under
"trunk" put my source?

Does the "trunk" folder show up in Visual Studio the same way?

I plan on using TortoiseSVN to update/commit code, but eventually want to
use the VisualSVN Visual Studio add-on.

[Andy Shellam]

Hi,

We use Visual Studio 2005/2008 with TortoiseSVN and VisualSVN and find
it very stable.

I would recommend having your trunk/tags/branches folder as the first
level of folders in your repository, then your solution folders in
your trunk to begin with and projects under your solution folder.

I say this because the solution files can also differ between
branches/tags/trunk dependent on what you're working on. For example
we have a large project (some 60 projects in a solution) and we're
currently working on 4 different working copies (trunk and 3
branches.) In the trunk I have a couple of projects that are new and
don't exist in the branches.

If I had my project laid out the way you're thinking, then every time
a developer loaded up the solution from the branch it would look for
my new projects even though they don't care about it, because there's
only 1 solution.

As a side-note, before committing anything to a new repository make
sure to set "bin" and "obj" as svn excludes. When you rebuild a
solution, Visual Studio deletes and recreates these folders in each
project. SVN can get extremely confused if it thinks they're under
version control but the .svn folders keep disappearing cause Visual
Studio deletes them.

Personally we also exclude *.suo (solution user options) files because
they're specific to a developer, and developers get annoyed if their
options keep getting overwritten by other people's :-P The only
downside is you can't version or share anything in these files, such
as Tasks.

Hope this helps,

Andy