SubWCRev.exe failing to ignore .subwcrevignore

[K Hansen]

I have my working directories on a mapped network drive O:\

My directory structure is:

O:\<SVN_trunk>

\bootloader_directory

\common_files

\documents

\libraries

\Project_directory

\source

\output

\SVN_files

build.c

build.h

subversion.tmp

SubWCRev.exe

\utilities

.subwcrevignore

project.uvmpw

The .subwcrevignore file contains:

*.uvmpw

bootloader_directory

bootloader_directory/*

documents

documents/*

Project_directory/output

Project_directory/output/*

utilities

utilities/*

The command line we're using is:

O:\<SVN_trunk>\SVN_files\SubWCRev.exe O:\<SVN_trunk> O:\<SVN_trunk>\SVN_files\subversion.tmpl O:\<SVN_trunk>\SVN_files\build.c

However, when the SubWCRev.exe command line is run as part of the release pre-build process, it fails due to local modifications of the project.uvmpw file and the Project_directory/output files, both of which are defined in the .subwcrevignore file.

What am I missing?

[Stefan]

On Friday, September 4, 2020 at 12:43:25 PM UTC+2 K Hansen wrote:

I have my working directories on a mapped network drive O:\

you should not do that!

https://tortoisesvn.net/faq.html#wconshare 

 

 

However, when the SubWCRev.exe command line is run as part of the release pre-build process, it fails due to local modifications of the project.uvmpw file and the Project_directory/output files, both of which are defined in the .subwcrevignore file.

why/how does it fail? What's the error?

 

[Kristin Hansen]

On Fri, 4 Sep 2020, 18:22 Stefan via TortoiseSVN, <torto...@googlegroups.com> wrote:

On Friday, September 4, 2020 at 12:43:25 PM UTC+2 K Hansen wrote:

I have my working directories on a mapped network drive O:\

you should not do that!

https://tortoisesvn.net/faq.html#wconshare 

Thank you for pointing that out, but it's been set up this way for over a year and no issues, so I can't justify pushing the change at the mo. It's not my actual problem anyway 

However, when the SubWCRev.exe command line is run as part of the release pre-build process, it fails due to local modifications of the project.uvmpw file and the Project_directory/output files, both of which are defined in the .subwcrevignore file.

why/how does it fail? What's the error?

Our build.c template is set up to stop on an error if local modifications are detected in the files under SVN control. This is to prevent generating release code from un-checked in files. The files that change are the project file (when I enable the release build batch file) and the output files (when it cleans the output directory prior to the build).

My question is specifically how to get the .subwcrevignore file to work, as subwcrev.exe is not currently ignoring the files and directories I've identified.

--
You received this message because you are subscribed to the Google Groups "TortoiseSVN" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tortoisesvn...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/tortoisesvn/684a5d4e-5bf3-4ca4-a624-c98af09f653an%40googlegroups.com.

[Stefan]

On Friday, September 4, 2020 at 8:09:36 PM UTC+2 K Hansen wrote:

On Fri, 4 Sep 2020, 18:22 Stefan via TortoiseSVN, <torto...@googlegroups.com> wrote:

On Friday, September 4, 2020 at 12:43:25 PM UTC+2 K Hansen wrote:

I have my working directories on a mapped network drive O:\

you should not do that!

https://tortoisesvn.net/faq.html#wconshare 

Thank you for pointing that out, but it's been set up this way for over a year and no issues, so I can't justify pushing the change at the mo. It's not my actual problem anyway 

However, when the SubWCRev.exe command line is run as part of the release pre-build process, it fails due to local modifications of the project.uvmpw file and the Project_directory/output files, both of which are defined in the .subwcrevignore file.

why/how does it fail? What's the error?

Our build.c template is set up to stop on an error if local modifications are detected in the files under SVN control. This is to prevent generating release code from un-checked in files. The files that change are the project file (when I enable the release build batch file) and the output files (when it cleans the output directory prior to the build).

My question is specifically how to get the .subwcrevignore file to work, as subwcrev.exe is not currently ignoring the files and directories I've identified.

again: what's the error that SubWCRev returns? Or what is the indicator that SubWCRev does not ignore the files?

You only said that it doesn't ignore the files, but how do you detect that? What's the output of SubWCRev that you're expecting and what actually happens?

 

[Kristin Hansen]

I'll have to delve into that next week when I'm back at work. I think it's simply that local mods have been detected as, off the top of my head, there's something like $WCMOD$ in the template. I've not got it to hand right now.

Thanks for the help and I'll let you know what's in the template on Monday.

Cheers

Kristin

--

You received this message because you are subscribed to the Google Groups "TortoiseSVN" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tortoisesvn...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/tortoisesvn/6c9ec1b8-ba56-433c-af63-3bb4531ec818n%40googlegroups.com.

[Kristin Hansen]

The code in the template file is:

#if $WCMODS?1:0$
#error Source is modified
#endif

This halts the release build if there are any local modifications detected. 

The .subwcrevignore is intended to mask out irrelevant files so that local modifications are not detected and the release code is built. However, at the moment this is not working and I don't know why.

Regards

Kristin

[Stefan]

I just tested this here, and it works as it should.

So, a few things you might want to check:

• the .subwcrevignore file must be at the wc root or the path you specify for SubWCRev
• the ignore patterns are case-sensitive!
• the ignore pattern paths need forward slashes, not backslashes
• the ignore pattern paths are relative to the path where the .subwcrevignore file is

apart from that, I can't see what else might be the problem here.

As I said, it works fine for me, and I've tried multiple ignore patterns just to be sure.

Stefan

[Kristin Hansen]

There must be something I'm still missing then? 

My project is fully up to date. 

I've edited my .subwcrevignore file to only contain: *.subwcrevignore.

This is now the only modified file in the entire project folder.

Both the subwcrev.eve and .subwcrevignore file are in O:\trunk\SVN_files

When I run the command:

O:\trunk\SVN_files\SubWCRev.exe O:\trunk\SVN_files

I get the output:

SubWCRev: 'O:\trunk\SVN_files'
Last committed at revision 3907
Updated to revision 3907
Unversioned items found

When I run the command:

O:\trunk\SVN_files\SubWCRev.exe O:\trunk

I get the output:

SubWCRev: 'O:\trunk'
Last committed at revision 3907
Updated to revision 3907
Local modifications found
Unversioned items found

I have tried adding SVN_files, ../SVN_files and O:/trunkSVN_files to the .subwcrevignore file but each time it makes no difference.

Any ideas?

--

You received this message because you are subscribed to the Google Groups "TortoiseSVN" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tortoisesvn...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/tortoisesvn/291b3384-6a95-424f-b772-ee5abdc7da1an%40googlegroups.com.

[Stefan]

On Wednesday, September 9, 2020 at 4:11:30 PM UTC+2 K Hansen wrote:

There must be something I'm still missing then? 

My project is fully up to date. 

I've edited my .subwcrevignore file to only contain: *.subwcrevignore.

This is now the only modified file in the entire project folder.

Both the subwcrev.eve and .subwcrevignore file are in O:\trunk\SVN_files

When I run the command:

O:\trunk\SVN_files\SubWCRev.exe O:\trunk\SVN_files

I get the output:

SubWCRev: 'O:\trunk\SVN_files'
Last committed at revision 3907
Updated to revision 3907
Unversioned items found

When I run the command:

O:\trunk\SVN_files\SubWCRev.exe O:\trunk

I get the output:

SubWCRev: 'O:\trunk'
Last committed at revision 3907
Updated to revision 3907
Local modifications found
Unversioned items found

When you run subwcrev on O:\trunk, then the .subwcrevignore file must also be at O:\trunk.

Because the .subwcrevignore file is only read at the wc root and the specified path. The wc is not searched downwards for it!

[Kristin Hansen]

Ah... ok... I only moved the .subwcrevignore file because of your comment above:

• the .subwcrevignore file must be at the wc root or the path you specify for SubWCRev

I've moved it back to O:\trunk now and it's fine running with no local modifications detected. 

However, local modifications are detected when I modify a file in O:\trunk\project and edit the .subwcrevignore file to be:

*.subwcrevignore

project

project/*

And also if I edit the .subwcrevignore file to be:

*.subwcrevignore

/trunk/project

/trunk/project/*

These are the two ignore patterns mentioned in https://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-subwcrev.html 

I am running the latest TortoiseSVN:

TortoiseSVN 1.14.0, Build 28885 - 64 Bit , 2020/05/24 13:32:45
ipv6 enabled
Subversion 1.14.0, -release
apr 1.6.5
apr-util 1.6.1
serf 1.3.9
OpenSSL 1.1.1g  21 Apr 2020
zlib 1.2.11
SQLite 3.29.0

--
You received this message because you are subscribed to the Google Groups "TortoiseSVN" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tortoisesvn...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/tortoisesvn/10e31c7c-e001-46a0-b603-0068b2463d4fn%40googlegroups.com.

[Kristin Hansen]

Problem solved! A combination of operator error and legacy systems getting in the way.

If I update the SubWCRev.exe that's saved and under version control in O:\trunk\SVN_files to the latest installed version under C:\Program Files, it's all happy.

I don't know why they originally decided to do it that way, but there you go, the joys of inheriting code!

THANK YOU for all your help solving this non-problem!

Regards

Kristin