You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Igor DEFAYE <i....@sitealpha.ca> on 2011/08/09 19:57:05 UTC

updates on subdirectories : revision not being pulled

Hello,

 

We have a major problem on our Apache Subversion. When updating some
revisions are not pulled down to the pc, regardless of which pc we use. 

This seems to happen only when updating from a sub-directory and not
updating from root directory, but it might also happen from root dir,
I've just haven't seen it happen yet.

I don't know if this is an already known issue, or if I need to submit a
new one. So I hope someone can help me look rapidly over this.

 

Our server is up to date : 1.6.17 build 2190.74 . We administer the
server via Collabnet Subversion Edge. We mostly use tortoise svn
clients, they were updated but the problem is server side.

 

We have noticed the revisions that are not pulled down to the pcs also
do not appear in the change log on the subdirectory, but does on higher
directories. 

 

May be an example will make it clearer  :

On root directory we see the change log for revision 20445, it concerns
only one file : /SuiteFM_dot_Net/Bin/www/ope_RAPPORT/js/container.js

Both Collabnet or tortoise show the same, so far so good.

Here are some screen shot : 

  

 

Now if we go directly on the concerned file by the revision to get a
change log, this is what we get :

 

 

As you can see revision 20445 is just not there.

We see the same on Colabnet Subversion Edge, so we are pretty sure it's
not a client problem.

 

 

 

 

Now if we go back in the directory structure, the revision is missing on
:

-          /SuiteFM_dot_Net/Bin/www/ope_RAPPORT/js/container.js

-          /SuiteFM_dot_Net/Bin/www/ope_RAPPORT/js/

-          /SuiteFM_dot_Net/Bin/www/ope_RAPPORT/

But not on :

-          /SuiteFM_dot_Net/Bin/www/

-          /SuiteFM_dot_Net/Bin/

-          /SuiteFM_dot_Net/

 

So depending on how deep ones updates, we get or not the latest revision
of files.

 

This is just an example of various cases we have had, not all have been
detected yet. This is particularly dangerous, because when committing
the file is replaced with an older version without anyone knowing until
a bug is seen. Right now we are unsure at how stable our application is,
it's impossible to track down the commit that reverted code. The more we
commit the more we risk deteriorating the version.

 

So any help would be quite appreciated.

 

Thanks in advance.

 

Igor Defaye

Development Team Manager. 

Site Alpha Group Plannon

 

 

 

 


Re: updates on subdirectories : revision not being pulled

Posted by Mark Phippard <ma...@gmail.com>.
On Tue, Aug 9, 2011 at 1:57 PM, Igor DEFAYE <i....@sitealpha.ca> wrote:


> We have a major problem on our Apache Subversion. When updating some
> revisions are not pulled down to the pc, regardless of which pc we use.
>
> This seems to happen only when updating from a sub-directory and not
> updating from root directory, but it might also happen from root dir, I’ve
> just haven’t seen it happen yet.****
>
> ****
>
> I don’t know if this is an already known issue, or if I need to submit a
> new one. So I hope someone can help me look rapidly over this.****
>
> ** **
>
> Our server is up to date : 1.6.17 build 2190.74 . We administer the server
> via Collabnet Subversion Edge. We mostly use tortoise svn clients, they were
> updated but the problem is server side.****
>
> ** **
>
> We have noticed the revisions that are not pulled down to the pcs also do
> not appear in the change log on the subdirectory, but does on higher
> directories. ****
>
> ** **
>
> May be an example will make it clearer  :****
>
> On root directory we see the change log for revision 20445, it concerns
> only one file : /SuiteFM_dot_Net/Bin/www/ope_RAPPORT/js/container.js****
>
> Both Collabnet or tortoise show the same, so far so good.
>

Please do not mail dev@.  This is not a discussion about the development of
Subversion.

Based on your screenshots, I would suggest you look at revision 20453.  If
someone replaced the folder in that commit with an earlier version from its
history than everything in your screenshots makes perfect sense.  Basically
@ revision 20453, the folder was replaced, creating a new line of history
that does not include those other revisions.


-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/