JavaHL and Transactions

2015-08-17 Thread corneil.duples...@gmail.com 
I am in the process of developing a set of utilities for managing the
'promotion' of code from trunk to specific tags etc. The project has been
doing tag based development for more than 10 years and is now moving from
CVS to SVN.

I am using the JavaHL api from org.apache.subversion.javahl
>From my experience as a user of Subversion in Eclipse and other tools I
come to expect support for performing multiple operations in a
'transaction' which results in one new version with the relevant comments.

I cannot figure out how to do this with the JavaHL api.

As an example:
Give the following structure:
PROJECT1/trunk/sub-project1/files/test.txt
PROJECT1/trunk/sub-project1/files/test2.txt
PROJECT1/trunk/sub-project1/morefiles/test3.txt

A promotion of sub-project1 to 'integration' would entail
copy from PROJECT1/trunk/sub-project1 to PROJECT1/tags/integration/sub-
project1
This can be done on cmd line using svn copy


Assume someone then modifies test2.txt and test3/txt on trunk and committed
those changes. Our requirements are to make a backup of the target sub
project before applying the changes so that a 'demote' can be performed if
needed.
A new promotion should now entail:
create:
PROJECT1/tags/BACKUP_integration_20150812_180902_username/sub-project1/files
PROJECT1/tags/BACKUP_integration_20150812_180902_username/sub-project1/morefiles
move the files that are being modified:
PROJECT1/tags/integration/sub-project1/files/test2.txt to
PROJECT1/tags/BACKUP_integration_20150812_180902_username/sub-project1/files/test2.txt
PROJECT1/tags/integration/sub-project1/morefiles/test3.txt to
PROJECT1/tags/BACKUP_integration_20150812_180902_username/sub-project1/morefiles/test3.txt
copy the file that is not modified:
PROJECT1/tags/integration/sub-project1/files/test.txt to
PROJECT1/tags/BACKUP_integration_20150812_180902_username/sub-project1/files/test.txt
copy the modified files from trunk to tags/integration
PROJECT1/trunk/sub-project1/files/test2.txt to
PROJECT1/tags/integration/sub-project1/files/test2.txt
PROJECT1/trunk/sub-project1/morefiles/test3.txt to
PROJECT1/trunk/sub-project1/morefiles/test3.txt


To perform these operations involve multiple api calls and a new version
for each operation.
The api allows for multiple files are in the same source and target folder
in the case of copy and move operations.

It would be some much cleaner with transactions resulting in one new
version so that it is easy to identify all the related operations.

>From an exploration of the C api it seems that transactions are supported.
I would like to know if I have missed something somewhere.


Regards
Corneil du Plessis

JavaHL logMessages only one callback

2015-08-19 Thread corneil.duples...@gmail.com 
I am trying to find change history and thought that using logMessage will
provide the information.

I am using a call as descibre below:

pegRevision = Revision.HEAD,
ranges = [RevisionRange(Revision.HEAD, Revision.START)]
stopOnCopy = false
discoverPath = true
includeMergedRevisions = true
props = [REV_LOG, REV_DATE, REV_AUTHOR]
limit = -1

May callback function is only called once with the last commit information.

I tried:
stopOnCopy true and false
limt -1, 0, 1000
includeMergedRevisions = true and false
ranges with  RevisionRange(Revision.START, Revision.HEAD)

I never receive more than one callback.

Then I tried something different:

determine maxRev after previous list operation.

ranges = RevisionRange(maxRev + "-0")

and now I get all the versions.

It seems as if the RevisionRange(Revision.HEAD, Revision.START) is not
being treated as expected.

Am I misunderstanding the RevisionRange class?

Corneil du Plessis

Re: JavaHL logMessages only one callback

2015-08-19 Thread corneil.duples...@gmail.com 
Thanks, the following worked and only difference was the order of the
callbacks.

RevisionRange(Revision.getInstance(0), Revision.HEAD)
RevisionRange(Revision.HEAD, Revision.getInstance(0))



Corneil du Plessis
about.me/corneil


On 19 August 2015 at 11:04, Branko Čibej  wrote:
>
> On 19.08.2015 10:48, corneil.duples...@gmail.com wrote:
> > I am trying to find change history and thought that using logMessage
will
> > provide the information.
> >
> > I am using a call as descibre below:
> >
> > pegRevision = Revision.HEAD,
> > ranges = [RevisionRange(Revision.HEAD, Revision.START)]
> > stopOnCopy = false
> > discoverPath = true
> > includeMergedRevisions = true
> > props = [REV_LOG, REV_DATE, REV_AUTHOR]
> > limit = -1
> >
> > May callback function is only called once with the last commit
information.
> >
> > I tried:
> > stopOnCopy true and false
> > limt -1, 0, 1000
> > includeMergedRevisions = true and false
> > ranges with  RevisionRange(Revision.START, Revision.HEAD)
> >
> > I never receive more than one callback.
>
> I really wish you'd shown actual code, not some description of code ...
> it's easier to understand.
>
>
> > Then I tried something different:
> >
> > determine maxRev after previous list operation.
> >
> > ranges = RevisionRange(maxRev + "-0")
> >
> > and now I get all the versions.
> >
> > It seems as if the RevisionRange(Revision.HEAD, Revision.START) is not
> > being treated as expected.
>
>
> Actually, it is, but Revision.START is really badly documented ... it's
> the same as Revision.UNSPECIFIED and it's only useful in some limited
> contexts.
>
> You could try using RevisionRange(Revision.HEAD, Revision.getInstance(0))
>
> -- Brane

Re: Configure username

2015-12-15 Thread corneil.duples...@gmail.com 
Try
svn+ssh://username@some/path/project/trunk


[image: --]
Corneil du Plessis
[image: https://]about.me/corneil


On 16 December 2015 at 05:49, Anshul Guleria 
wrote:

>  Hi,
> I am trying to checkout my svn repo which is like
>
>
>
> *svn+ssh://some/path/to/project/trunk*
> And the user required for access to this repo is different than from my
> ubuntu user, but it automatically picks the user from my ubuntu. How to
> configure to use a different username than the system login user.
>
> I tried
> svn --username somename checkout svn+ssh://some/path/to/project/trunk
>
> but it still not picks up the provided username.
>
>
>
> --
> signature?
>

Re: Subversion Server Replacement Query

2017-09-20 Thread corneil.duples...@gmail.com 
In short:
Don't host on NFS or any remote filesystem.
It is better to dump and import, you can do the dump with old or new
version but will only benefit from all new features and stability with the
repository in the newer version.




[image: --]
Corneil du Plessis
[image: https://]about.me/corneil


On 20 September 2017 at 11:06, Saleh, Mai  wrote:

> Hi Subversion Support,
>
>
>
> Please advise as we need to move subversion from old server with OS RH5U3
> to RH7U3, all of our repositories are hosted on NFS share.
>
> SVN version on old server is 1.6.x and new server has version 1.9.7.
>
>
>
> Plan is to rsync old shared area hosting repositories to new shared area
> and copy configuration files to the same path on new server. So
> repositories and configuration files will be in exact paths. Then we will
> rename new server with original server name.
>
>
>
>
>
> Initial test succeeded, but we need to know is there anything that we need
> to take care of, do we have to use dump and load as that will take lots of
> time, due to history and size of repositories.
>
>
>
> Do users need to create a new working copies?
>
>
>
>
>
>
>
>
>
> *Thanks & BRs*
>
>
>
> *Mai Saleh*
>
> *IT Global Technologies & Infrastructure*
>
> *Software Tools Engineer*
>
>
>

Re: Subversion Server Replacement Query

2017-09-20 Thread corneil.duples...@gmail.com 
The user's working copies should be fine. In my experience older clients
are fine with newer servers and newer clients are fine with older workspace
formats.



[image: --]
Corneil du Plessis
[image: https://]about.me/corneil
<https://about.me/corneil?promo=email_sig>

On 20 September 2017 at 12:29, Saleh, Mai  wrote:

> Hi Corneil,
>
>
>
> Thanks a million for your reply.
>
> It has been years since we use NFS, so no worries about that.
>
>
>
> Can I know please what will be the risk to use rsync as it worked in our
> tests.
>
>
>
> Do users need to create a new working copies after moving to new version?
>
>
>
>
>
>
>
>
>
> *Thanks & BRs*
>
>
>
> *Mai Saleh*
>
> *IT Global Technologies & Infrastructure*
>
> *Software Tools Engineer*
>
>
>
> *From:* corneil.duples...@gmail.com [mailto:corneil.duples...@gmail.com]
> *Sent:* Wednesday, September 20, 2017 12:23 PM
> *To:* Saleh, Mai 
> *Cc:* users@subversion.apache.org
> *Subject:* Re: Subversion Server Replacement Query
>
>
>
> In short:
>
> Don't host on NFS or any remote filesystem.
>
> It is better to dump and import, you can do the dump with old or new
> version but will only benefit from all new features and stability with the
> repository in the newer version.
>
>
>
>
>
>
> *Corneil du Plessis*
>
> about.me/corneil
>
>
>
>
>
> On 20 September 2017 at 11:06, Saleh, Mai  wrote:
>
> Hi Subversion Support,
>
>
>
> Please advise as we need to move subversion from old server with OS RH5U3
> to RH7U3, all of our repositories are hosted on NFS share.
>
> SVN version on old server is 1.6.x and new server has version 1.9.7.
>
>
>
> Plan is to rsync old shared area hosting repositories to new shared area
> and copy configuration files to the same path on new server. So
> repositories and configuration files will be in exact paths. Then we will
> rename new server with original server name.
>
>
>
>
>
> Initial test succeeded, but we need to know is there anything that we need
> to take care of, do we have to use dump and load as that will take lots of
> time, due to history and size of repositories.
>
>
>
> Do users need to create a new working copies?
>
>
>
>
>
>
>
>
>
> *Thanks & BRs*
>
>
>
> *Mai Saleh*
>
> *IT Global Technologies & Infrastructure*
>
> *Software Tools Engineer*
>
>
>
>
>

Re: Subversion Server Replacement Query

2017-09-20 Thread corneil.duples...@gmail.com 
The subversion documentation doesn't advise copying the repositories to a
new 'machine' or installation.
I have always used dump and load. I repository that was converted from CVS
with more than 50k files, 2-3million lines of code and 15years old was 3GB
in side and took 2 hours to dump and load.
I am not sure what you have that will take a week.



[image: --]
Corneil du Plessis
[image: https://]about.me/corneil
<https://about.me/corneil?promo=email_sig>

On 20 September 2017 at 14:27, Saleh, Mai  wrote:

> I will really appreciate, if you could help in “Can I know please what
> will be the risk to use rsync as it worked in our tests.”
>
> Why do we have to take dump and load, that will take week due to number
> and size, if you can clarify why not just take a copy of current
>  repositories to new shared area via rsync, will be great J
>
>
>
> *Thanks & BRs*
>
>
>
> *Mai Saleh*
>
> *IT Global Technologies & Infrastructure*
>
> *Software Tools Engineer*
>
>
>
> *From:* corneil.duples...@gmail.com [mailto:corneil.duples...@gmail.com]
> *Sent:* Wednesday, September 20, 2017 2:15 PM
> *To:* Saleh, Mai 
> *Cc:* users@subversion.apache.org
> *Subject:* Re: Subversion Server Replacement Query
>
>
>
> The user's working copies should be fine. In my experience older clients
> are fine with newer servers and newer clients are fine with older workspace
> formats.
>
>
>
>
> *Corneil du Plessis*
>
> about.me/corneil
>
>
>
>
>
> On 20 September 2017 at 12:29, Saleh, Mai  wrote:
>
> Hi Corneil,
>
>
>
> Thanks a million for your reply.
>
> It has been years since we use NFS, so no worries about that.
>
>
>
> Can I know please what will be the risk to use rsync as it worked in our
> tests.
>
>
>
> Do users need to create a new working copies after moving to new version?
>
>
>
>
>
>
>
>
>
> *Thanks & BRs*
>
>
>
> *Mai Saleh*
>
> *IT Global Technologies & Infrastructure*
>
> *Software Tools Engineer*
>
>
>
> *From:* corneil.duples...@gmail.com [mailto:corneil.duples...@gmail.com]
> *Sent:* Wednesday, September 20, 2017 12:23 PM
> *To:* Saleh, Mai 
> *Cc:* users@subversion.apache.org
> *Subject:* Re: Subversion Server Replacement Query
>
>
>
> In short:
>
> Don't host on NFS or any remote filesystem.
>
> It is better to dump and import, you can do the dump with old or new
> version but will only benefit from all new features and stability with the
> repository in the newer version.
>
>
>
>
>
>
> *Corneil du Plessis*
>
> about.me/corneil
>
>
>
>
>
> On 20 September 2017 at 11:06, Saleh, Mai  wrote:
>
> Hi Subversion Support,
>
>
>
> Please advise as we need to move subversion from old server with OS RH5U3
> to RH7U3, all of our repositories are hosted on NFS share.
>
> SVN version on old server is 1.6.x and new server has version 1.9.7.
>
>
>
> Plan is to rsync old shared area hosting repositories to new shared area
> and copy configuration files to the same path on new server. So
> repositories and configuration files will be in exact paths. Then we will
> rename new server with original server name.
>
>
>
>
>
> Initial test succeeded, but we need to know is there anything that we need
> to take care of, do we have to use dump and load as that will take lots of
> time, due to history and size of repositories.
>
>
>
> Do users need to create a new working copies?
>
>
>
>
>
>
>
>
>
> *Thanks & BRs*
>
>
>
> *Mai Saleh*
>
> *IT Global Technologies & Infrastructure*
>
> *Software Tools Engineer*
>
>
>
>
>
>
>