I am having a strange problem where files are automatically added to my
working copy.
When I do a build of my project, and /bin directory appears, (naturally)
along with all of the results of my build. The weird thing is that when
I look at the directory, it's got a red check, it has a .svn folder, and
every folder within the new /bin directory also has the same problem.
It's very strange. Note, only the folders are appearing in the entries
files. The files aren't actually getting added.
I did a search on "automatically", and I found a guy who wishes he
had my problem:
http://tortoisesvn.tigris.org/servlets/ReadMsg?list=users&msgNo=7802
He WANTS new files to be automatically and transparently added to his
working copy. I can't seem to stop it from happening!
Anybody have any idea of what's going on?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-un...@tortoisesvn.tigris.org
For additional commands, e-mail: users...@tortoisesvn.tigris.org
When you do your build, is it started by copying a versioned directory
(or contents of a versioned directory, including all subdirectories)
into this bin directory?
I have another machine sitting right beside me where this isn't happening.
Same exact project.
I do a "revision graph" of the /bin folder, which tsvn thinks is in the wc but
really isn't, and I get the revision graph for my /src folder. Joy.
That indicates that your build somehow copies files from your source
folder to the bin folder, but does not ignore the .svn or _svn folders.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
But do you have svn installed there with identical settings too?
are the .svn folders there called _svn maybe? Or vice versa?
> 2. I don't think the build process is copying the files over, because the
> all the .svn files have a new timestamp, as if they were modified by
> something that speaks svn. The .svn directories in the /src tree have
> timestamps as expected, but the .svn folders and the files within
> have timestamps that match the time of the build.
If you copy a folder, the timestamp of the folder always changes. Only
files keep their timestamp depending on how you copy them.
> 3. Something else weird - the new .svn directories in the /bin tree
> all have the hidden attribute set to false.
That indicates that something copies them without knowing that these are
Subversion folders.
> I did check to see the contents of the entries files in the /bin tree,
> and the couple that I checked did have identical contents to the
> 'real' files in the /src tree.
So they get *copied*.
I can assure you that TSVN does *not* copy files without being asked to.
I thought maybe you were right, so I created a file called
"CopyMeIdoubleDareYou.txt" and put it in my /src/.svn folder. I did a
build, and low and behold, there it appeared in the /bin/.svn folder.
So, I thought you were right. But, then I checked the timestamps,
and they didn't make sense.
All of the svn related files and folders had the timestamp of the
moment of the build, but the timestamp for my "CopyMe" file remained
unchanged.
So, I tried again.
Now when I do a build, the /bin folder doesn't get a .svn folder, but each
folder underneath it does.
So, I put my "CopyMeIdoubleDareYou.txt" file into the /src/com/.svn
folder. Guess what, it does not get copied to /bin/com/.svn
Another item, the prop-base and text-base folders in the .svn folders
are NOT appearing the the /bin tree.
Something very, very weird is happening. I *do not* suspect that TSVN
is copying files. I do not believe these files are being copied, I think they
are being created. (Except for files in the root /src folder, which I think
are being assumed to be resources, and copied to /bin. Files in /src/com
and below do not appear to be subject to being copied.)
I now suspect some sort of obscure failure in eclipse. This baffles me,
because there is no subversion support installed on this instance of
eclipse.
---------------------------------------------------------------------
What is the best way to backup the repository if you are using a file based
repo and do not have subversion installed. All repo backup references I
have see all use SVNAdmin hotcopy. Since SVNAdmin does not exist on a
non-Subversion install, that's not an option.
Is it safe to just drag and drop a copy of the repository folder to the
backup destination? Any problem with Windows backup backing up the folder
to tape or to CD?
TIA - Tom
You could just install subversion - there is a Windows installer :-)
> Is it safe to just drag and drop a copy of the repository folder to the
> backup destination? Any problem with Windows backup backing up the folder
> to tape or to CD?
For FSFS repositories it should be safe to do this, but be sure you
are not accessing it at the time. For BDB I believe it is not safe to
do this.
For a more definitive answer ask on the Subversion users list.
Simon
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
---------------------------------------------------------------------
On 19/03/2008, Paul Pcoder <paul....@gmail.com> wrote:
> Hello,
>
> I am having a strange problem where files are automatically added to my
> working copy.
>
> When I do a build of my project, and /bin directory appears, (naturally)
> along with all of the results of my build. The weird thing is that when
> I look at the directory, it's got a red check, it has a .svn folder, and
Try to get a log of the build process (are you using .bat/.cmd files,
make or other build scripts?). There *must* be some sort of copy being
done. The only way you can get a red check on a folder is to have
modifications inside a folder that has been committed at least once
(otherwise its status is 'added' and the icon is a blue plus sign).
Since you did not report any changes to the SVN revision number for
each build, I think you can rule out the possibility of a background
'add and commit' step in the build process.
Have you tried creating a bin folder and setting the svn:ignore to bin/*?
--
Regards,
Jean-Marc
----------------
___
// \\ @@ "De Chelonian Mobile"
/ \_/ \/._) TortoiseSVN
<\_/_\_/ / The coolest Interface to (Sub)Version Control
/_/ \_\ Check out http://tortoisesvn.net
> Try to get a log of the build process (are you using .bat/.cmd files,
> make or other build scripts?). There *must* be some sort of copy being
> done. The only way you can get a red check on a folder is to have
> modifications inside a folder that has been committed at least once
> (otherwise its status is 'added' and the icon is a blue plus sign).
Hi, thanks for your reply.
I agree, some copying is going on, or some logical equivalent of
copying is happening. It is very odd. The trouble is that the timestamps
don't make sense if it's a copy, and only some of the files under .svn
get duplicated in the /bin folder. If it's some sort of copy operation,
why don't the timestamps match, and why isn't it copying *all* of
the .svn related files?
You are right about the red check... I stupidly thought to myself, "OK,
svn thinks these files are in the repo, so I'll just delete them." You
can predict the results; since the entries files in /bin were identical
to the files in /src, I ended up whacking my /src tree out of the
repository. [ Que laughter from the audience, ha ha ha! ]
I do not have a log from the build process, there does not appear to
be any being created by eclipse that I could find. Eclipse is so
complicated under the covers, though. I swear, it's the emacs for
this decade.
At this time, I strongly suspect that something in Eclipse is going
horribly wrong. I am guessing that at some point I attempted to
install a SVN client plugin into Eclipse, and the install failed
miserably. The problem seems to be being caused by
*something* that understands SVN, but is horribly broken. A
broken Eclipse plugin is the only explanation I can see at this
point.
I dug into the plugin folders for Eclipse, and I found no
traces of any SVN functionality, but that doesn't mean it wasn't
there. Yesterday, I attempted to install a SVN plugin, hoping
that a working SVN client would clear things up, but my attempt
to install the plugin failed. Thus, I suspect something is wrong
on this installation, as things are working fine on my other box.
> Since you did not report any changes to the SVN revision number for
> each build, I think you can rule out the possibility of a background
> 'add and commit' step in the build process.
>
> Have you tried creating a bin folder and setting the svn:ignore to bin/*?
No, I have not done this. I really need both of my configurations to be
identical, so I'm going to either find out what is wrong and fix it, or
nuke this machine and start over.
It's starting to look like one of those days when using *one*
nuclear warhead just isn't enough...