Re: svnadmin hotcopy never ends

2015-05-04 Thread Johan Corveleyn
On Fri, May 1, 2015 at 2:21 PM, Ignacio González (Eliop)
 wrote:
> svnadmin 1.8.13
> Server: Centos 7 64-bit
> Repo in local xfs disk
> Backups in remote cifs share
>
> This operation works without problems:
> $ svnadmin hotcopy /path/to/repo /local/path/to/dest
> With a small repo, it takes just a few seconds
>
> But this one does not:
> $ svnadmin hotcopy /path/to/repo /remote/path/to/dest
>
> where /remote/path/to/dest is located on a remote cifs share.
>
> Before detailing the problem, let me tell you that this problem did not
> happen until I upgraded my server from Centos 5.5 & Subversion 1.6.16 &
> local repository over ext3 to the configuration described above. (The remote
> cifs share for backups is the same).
>
> Now, the symptons are these: when I launch the hotcopy operation, I can see
> that the repo is completely copied to the destination in a few seconds,
> except for 3 files. After several minutes (even hours), ps ux shows that
> svnadmin hotcopy is still active, but waiting for something that never
> happens... No error or warning message is shown.
>
> The three files are:
> /path/to/repo/format
> /path/to/repo/db/format
> /path/to/repo/db/fs-type

Can you tell us the contents of those three files please? That will
show us which format of the backend you're using (you've mentioned svn
1.6.16, and I'm not sure if you have 'svnadmin upgrade'd to the latest
backend format).

> It seems to me that these are the last files to be recreated in hotcopy
> operations, but I do not really know.
>
> The fact that the operation does succed on a local destination hints to some
> problem with permissions, different filesystems, or who knows.
>
> Here are the relevant parts of /etc/fstab, if they are needed:
>
> LABEL=repoxfs   /opt/csvn/data/repositories  xfs  defaults  1 2
> //srvr/bkps   /home/csvn/mnt/hotcopies   cifs
> username=csvn,domain=*,password=*,rw,uid=csvn,gid=csvn,dir_mode=0755,file_mode=0755
> 0 0

I have seen several hotcopy-fixes mentioned for the upcoming 1.9
release [1]. Maybe, as a test, you can try if the same problem still
happens with 1.9-beta1?

[1] search for 'hotcopy' in
http://svn.apache.org/repos/asf/subversion/trunk/CHANGES

-- 
Johan


Re: svnadmin hotcopy never ends

2015-05-04 Thread Eliop
Thanks for your answer, John.

I dumped and re-loaded the repositories, so the formats are the latest.

In the end, it was a problem with the cifs mount. I had to add "nobrl" to
the options in /etc/fstab:

//srvr/bkps   /home/csvn/mnt/hotcopies   cifs  nobrl,username=csvn,domain=*,
password=*,rw,uid=csvn,gid=csvn,dir_mode=0755,file_mode=0755 0 0

That did the trick.

2015-05-04 9:33 GMT+02:00 Johan Corveleyn :

> On Fri, May 1, 2015 at 2:21 PM, Ignacio González (Eliop)
>  wrote:
> > svnadmin 1.8.13
> > Server: Centos 7 64-bit
> > Repo in local xfs disk
> > Backups in remote cifs share
> >
> > This operation works without problems:
> > $ svnadmin hotcopy /path/to/repo /local/path/to/dest
> > With a small repo, it takes just a few seconds
> >
> > But this one does not:
> > $ svnadmin hotcopy /path/to/repo /remote/path/to/dest
> >
> > where /remote/path/to/dest is located on a remote cifs share.
> >
> > Before detailing the problem, let me tell you that this problem did not
> > happen until I upgraded my server from Centos 5.5 & Subversion 1.6.16 &
> > local repository over ext3 to the configuration described above. (The
> remote
> > cifs share for backups is the same).
> >
> > Now, the symptons are these: when I launch the hotcopy operation, I can
> see
> > that the repo is completely copied to the destination in a few seconds,
> > except for 3 files. After several minutes (even hours), ps ux shows that
> > svnadmin hotcopy is still active, but waiting for something that never
> > happens... No error or warning message is shown.
> >
> > The three files are:
> > /path/to/repo/format
> > /path/to/repo/db/format
> > /path/to/repo/db/fs-type
>
> Can you tell us the contents of those three files please? That will
> show us which format of the backend you're using (you've mentioned svn
> 1.6.16, and I'm not sure if you have 'svnadmin upgrade'd to the latest
> backend format).
>
> > It seems to me that these are the last files to be recreated in hotcopy
> > operations, but I do not really know.
> >
> > The fact that the operation does succed on a local destination hints to
> some
> > problem with permissions, different filesystems, or who knows.
> >
> > Here are the relevant parts of /etc/fstab, if they are needed:
> >
> > LABEL=repoxfs   /opt/csvn/data/repositories  xfs  defaults  1 2
> > //srvr/bkps   /home/csvn/mnt/hotcopies   cifs
> >
> username=csvn,domain=*,password=*,rw,uid=csvn,gid=csvn,dir_mode=0755,file_mode=0755
> > 0 0
>
> I have seen several hotcopy-fixes mentioned for the upcoming 1.9
> release [1]. Maybe, as a test, you can try if the same problem still
> happens with 1.9-beta1?
>
> [1] search for 'hotcopy' in
> http://svn.apache.org/repos/asf/subversion/trunk/CHANGES
>
> --
> Johan
>


Branch issue

2015-05-04 Thread Jan De Luyck
Hello folks,

Perhaps a stupid subversion question, but one i haven't been able to figure
out yet:

I've got two scripts in the same directory, which are basically variants -
one for RHEL6, one for RHEL7. Most of the content will be the same, with
small changes here and there. The files are named according to the RHEL
version.

Unfortunatly the scripts have to be completely self-contained, so using
modules/shared libraries/... is not an option.

Ideally I'd like to only have to manage one script, and pull the changes
into the second. But sofar I  haven't figured out a way yet to do this. The
only thing I thought of is moving both to a separate dir, and branching one
from the other. Doesn't seem ideal though.

Any pointers/ideas how I could tackle this?

Kind regards

Jan


Re: Branch issue

2015-05-04 Thread KM
In my opinion this sounds more like a coding issue than a source control issue, 
unless I am misunderstanding you. I don't think svn should be used to control 
the contents of your files.  You need to make the script generic so one version 
will work for all versions of RHEL.  Then you may control one script with svn.  
There are probably plenty of shell programming mechanisms you may use to get 
the script to be more vanilla or generic and work on all RHEL versions.  If 
they indeed need to be very different then you should control them separately.
This is just my opinion though.KM
   From: Jan De Luyck 
 To: users@subversion.apache.org 
 Sent: Monday, May 4, 2015 8:14 AM
 Subject: Branch issue
   
Hello folks,
Perhaps a stupid subversion question, but one i haven't been able to figure out 
yet:
I've got two scripts in the same directory, which are basically variants - one 
for RHEL6, one for RHEL7. Most of the content will be the same, with small 
changes here and there. The files are named according to the RHEL version.
Unfortunatly the scripts have to be completely self-contained, so using 
modules/shared libraries/... is not an option.
Ideally I'd like to only have to manage one script, and pull the changes into 
the second. But sofar I  haven't figured out a way yet to do this. The only 
thing I thought of is moving both to a separate dir, and branching one from the 
other. Doesn't seem ideal though.
Any pointers/ideas how I could tackle this?
Kind regards
Jan



  

Re: Branch issue

2015-05-04 Thread Jan De Luyck
While I agree with that, this is not a possibility right now. So I'm just
looking for an easy way to manage this, save from pulling diffs and
reapplying them.

Jan

On Mon, May 4, 2015 at 3:26 PM, KM  wrote:

> In my opinion this sounds more like a coding issue than a source control
> issue, unless I am misunderstanding you. I don't think svn should be used
> to control the contents of your files.  You need to make the script generic
> so one version will work for all versions of RHEL.  Then you may control
> one script with svn.
>
> There are probably plenty of shell programming mechanisms you may use to
> get the script to be more vanilla or generic and work on all RHEL
> versions.  If they indeed need to be very different then you should control
> them separately.
>
> This is just my opinion though.
> KM
>
>  --
>  *From:* Jan De Luyck 
> *To:* users@subversion.apache.org
> *Sent:* Monday, May 4, 2015 8:14 AM
> *Subject:* Branch issue
>
> Hello folks,
>
> Perhaps a stupid subversion question, but one i haven't been able to
> figure out yet:
>
> I've got two scripts in the same directory, which are basically variants -
> one for RHEL6, one for RHEL7. Most of the content will be the same, with
> small changes here and there. The files are named according to the RHEL
> version.
>
> Unfortunatly the scripts have to be completely self-contained, so using
> modules/shared libraries/... is not an option.
>
> Ideally I'd like to only have to manage one script, and pull the changes
> into the second. But sofar I  haven't figured out a way yet to do this. The
> only thing I thought of is moving both to a separate dir, and branching one
> from the other. Doesn't seem ideal though.
>
> Any pointers/ideas how I could tackle this?
>
> Kind regards
>
> Jan
>
>
>
>
>


Re: Branch issue

2015-05-04 Thread Branko Čibej
On 04.05.2015 14:14, Jan De Luyck wrote:
> Hello folks,
>
> Perhaps a stupid subversion question, but one i haven't been able to
> figure out yet:
>
> I've got two scripts in the same directory, which are basically
> variants - one for RHEL6, one for RHEL7. Most of the content will be
> the same, with small changes here and there. The files are named
> according to the RHEL version.
>
> Unfortunatly the scripts have to be completely self-contained, so
> using modules/shared libraries/... is not an option.
>
> Ideally I'd like to only have to manage one script, and pull the
> changes into the second. But sofar I  haven't figured out a way yet to
> do this. The only thing I thought of is moving both to a separate dir,
> and branching one from the other. Doesn't seem ideal though.
>
> Any pointers/ideas how I could tackle this?

Any copy is a branch. It doesn't have to be a copy of a directory.
Therefore, you can take one file, make a copy of it, put the contents of
the second file in the copy, and from then on just "svn merge" into the
copy every time you change something in the master file.

-- Brane