Re: SVN Access violation crash

2013-01-31 Thread Thorsten Schöning 
Guten Tag Mark Peters,
am Mittwoch, 30. Januar 2013 um 23:37 schrieben Sie:

>  C:\src-trunk-cpp\boingowifi\win8\build>svn ci -m "Increment
> project build number." --username dev --password GoBoingo
> ..\project\BoingoWiFinder\BoingoWiFinder\MainPage.xaml.cs
>  This application has halted due to an unexpected error.

http://mail-archives.apache.org/mod_mbox/subversion-users/201301.mbox/%3c20130129124928.gf25...@ted.stsp.name%3e

Mit freundlichen Grüßen,

Thorsten Schöning

-- 
Thorsten Schöning   E-Mail:thorsten.schoen...@am-soft.de
AM-SoFT IT-Systeme  http://www.AM-SoFT.de/

Telefon...05151-  9468- 55
Fax...05151-  9468- 88
Mobil..0178-8 9468- 04

AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow

[OPW] Introducing the 2013 Apache Subversion Intern

2013-01-31 Thread Gabriela Gibson 

Hi everyone,

I am the current Gnome Outreach Program for Women intern for the
Apache Subversion project, sponsored by Elego, Berlin, Germany.

OPW is a GNOME Woman initiative that aims to inspire women to
contribute to Free Software projects.

A short introduction to my official goals for the Apache Subversion
project in this internship can be found on my blog:

http://gabriela-gibson.blogspot.co.uk/2013/01/my-first-blog-post-hello-world-reloaded.html

I also have an Intern Desk which contains my playground where I keep
ideas and my to-do list here:

http://wiki.apache.org/subversion/GabrielaGibson

regards,

Gabriela

Re: [OPW] Introducing the 2013 Apache Subversion Intern

2013-01-31 Thread Nico Kadel-Garcia 
On Thu, Jan 31, 2013 at 7:24 AM, Gabriela Gibson
 wrote:
> Hi everyone,
>
> I am the current Gnome Outreach Program for Women intern for the
> Apache Subversion project, sponsored by Elego, Berlin, Germany.
>
> OPW is a GNOME Woman initiative that aims to inspire women to
> contribute to Free Software projects.

Wonderful: my female friends in computing, including my wife, have
sometimes found it difficult.

Although, there is something disturbing about the description"Gnome
Woman" initiative. It's difficult not to picture short women with red
caps and well groomed beards, one on every lawn in a suburb, mandated
by their local housing association. (My sense of humor has sometimes
been a source of despair for my wife.)

> A short introduction to my official goals for the Apache Subversion
> project in this internship can be found on my blog:
>
> http://gabriela-gibson.blogspot.co.uk/2013/01/my-first-blog-post-hello-world-reloaded.html
>
> I also have an Intern Desk which contains my playground where I keep
> ideas and my to-do list here:
>
> http://wiki.apache.org/subversion/GabrielaGibson
>
> regards,
>
> Gabriela

Cool. If you have any issues with getting cleanly built Subversion
packages without oddnesses of local libraries in development
environments, let me know. (I've dealt with a lot of that lately)

"svn info" does not work with symlink to different working copy

2013-01-31 Thread Michael Kaufmann 
Hi all,

I am using Subverison 1.7.8. On my disk are two Subversion working copies (from 
different repositories), and one working copy contains a symlink to the other:

/modules/test/dir/file.dat
/sources/test/modules -> ../../modules/test/


Unfortunately "svn info" does not work with an absolute path name in this 
scenario:

~$ svn info /sources/test/modules/dir
svn: warning: W155010: The node '/sources/test/modules/dir' was not found.

svn: E29: Could not display info for all targets because some targets don't 
exist


But it works when changing the directory before running "svn info":
~$ cd /sources/test/modules
/sources/test/modules$ svn info dir
[... valid "svn info" output ...]


I have not found anything about this behavior in the bug tracker.
Is this "by design" or is it a Subversion bug?

Regards,
Michael

Re: [OPW] Introducing the 2013 Apache Subversion Intern

2013-01-31 Thread C. Michael Pilato 
On 01/31/2013 07:54 AM, Nico Kadel-Garcia wrote:
> Although, there is something disturbing about the description"Gnome
> Woman" initiative. It's difficult not to picture short women with red
> caps and well groomed beards, one on every lawn in a suburb, mandated
> by their local housing association. (My sense of humor has sometimes
> been a source of despair for my wife.)

LOL!

(And as a guy whose sense of humor likewise encourages his wife's groaning,
I salute you.)


-- 
C. Michael Pilato 
CollabNet   <>   www.collab.net   <>   Enterprise Cloud Development



signature.asc
Description: OpenPGP digital signature

FreeBSD project and subversion.

2013-01-31 Thread Alfred Perlstein 
FreeBSD has moved to Subversion a few years ago and it's worked very, 
very well for us.


The one area where we are having issues is merging code from project 
branches back into trunk.


The typical workflow is:
  1) create project branch.
  2) code code code.
  3) sync from HEAD (this works great).
  4) repeat steps 2+3 until feature is complete.
  5) svn diff and apply to head then commit.

Is there a way to do 5 automatically?

I think the worry is mergeinfo from the project branch coming back into 
HEAD.


Any tips would be appreciated.

thank you,
-Alfred

Re: FreeBSD project and subversion.

2013-01-31 Thread Stefan Sperling 
On Thu, Jan 31, 2013 at 10:37:14AM -0500, Alfred Perlstein wrote:
> FreeBSD has moved to Subversion a few years ago and it's worked
> very, very well for us.

Thanks! That's encouraging to hear.

> The one area where we are having issues is merging code from project
> branches back into trunk.
> 
> The typical workflow is:
>   1) create project branch.
>   2) code code code.
>   3) sync from HEAD (this works great).
>   4) repeat steps 2+3 until feature is complete.
>   5) svn diff and apply to head then commit.
> 
> Is there a way to do 5 automatically?
> 
> I think the worry is mergeinfo from the project branch coming back
> into HEAD.
> 
> Any tips would be appreciated.

I've read the FreeBSD svn merging docs some time ago. I'm not sure if
changes have been made since, but it was probably an older version
of what currently lives at this URL:
  
http://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/subversion-primer.html

Back then I was somewhat worried that apparently the person who wrote them
didn't really understand much about how merges in Subversion work.

There was irrational fear of mergeinfo propagation, to the point where
the recommended practice is to remove mergeinfo before commit, which
any Subversion user with a clue will know is very wrong (expect in very
exceptional circumstances and only if you are equipped with sufficient
expertise to deal with the consequences).

What surprised me also was a complete lack of mention of the --reintegrate
option, which I suspect must be causing quite a lot of grief among FreeBSD
developers due to bogus conflicts during merges back into FreeBSD's head
branch (i.e. the trunk).

We'll need more details to help you in a constructive way, though.
Can you provide more details about your steps 1 to 5, i.e. show the
exact commands you're running in each step? The repository is public,
after all, which will help greatly with identifying and reproducing
specific problems. 

I'm happy to provide input for improving FreeBSD's docs to the point
where FreeBSD makes the best possible use of Subversion 1.7's merge
implementation, and can also provide some hints as to how future versions
of Subversion will improve to make life easier in certain cases.
 
BTW, I went over one of FreeBSD's svn wiki pages a while back, and added
answers to open questions on this page:
https://wiki.freebsd.org/SubversionMissing

One more point, which I like to bring up whenever a FreeBSD person shows
up on our lists: There is an outstanding patch in the FreeBSD ports tree
which should be shepherded into Subversion's upstream sources. I'm happy
to be the upstream point of contact for this but we also need someone
from the FreeBSD project to drive this and digest our feedback. Because
we want this feature to be generally usable and also avoid breaking
functionality that FreeBSD is relying on in their custom patch, of
course. So both sides need to be involved. See here for details:
http://subversion.tigris.org/issues/show_bug.cgi?id=890
(and also the mailing list threads linked from the issue)

svn:externals - process question

2013-01-31 Thread C M 
Hello,


My question is more process related with using svn:externals. In my
testing, it seems that the svn:externals links are bi-directional. Changes
are instantly propagated via the magic of svn:externals.

1. How do users preserve the integrity of a tag (which was created off a
branch which had svn:externals)?

Does  one simply delete the svn:externals link once the tag is created?

2. In the case of common code shared between different projects (link from
one to many), how are changes to the projects tracked?

Say, projects 1, 2 and 3 all use common code.  If project 1 makes changes
to common (in addition to other changes) and is slated for a release, what
now about projects 2 and 3? They too must be tagged to reflect the changes?
Is the the "normal" practice?

It seems like overhead to have to track and tag all projects affected by
common.

What are other ways of handling this in SVN?

Amad

Sorry for the double posts. Not sure what the protocol is on posting to
different lists.

Default values for args to svn_cmdline_create_auth_baton

2013-01-31 Thread Ryan Vordermann 
Hi,

My name is Ryan. I'm not subscribed to this list so I would appreciate
being CC'ed on responses

I'm working on a utility that uses the svn client api. Right now it works,
 but I want to add support for usernames and passwords. I do not (yet)
want to support any of the other security features.  What are the
 appropriate values for the following arguments to this function?

svn_cmdline_create_auth_baton

Currently I have this:
svn_boolean_t non_interactive = FALSE;
const char *config_dir = NULL;
svn_boolean_t no_auth_cache = FALSE;
svn_boolean_t trust_server_cert = FALSE;
svn_config_t *cfg_config = NULL;

Which so far works, but I was just taking a WAG.

Thanks in advance,
Ryan Vordermann

RE: svn:externals - process question

2013-01-31 Thread Andrew Reedick 
As you've discovered, externals *always* pull in the HEAD revision unless you 
specifically add a revision number to the svn:externals property.  Needless to 
say, "rogue" svn:externals are bad for build reproducibility and tagging.

Options are:
Audit the svn:externals (either manually, via a check-in hook, in the 
build/tagging script, etc.) in your checkedout/exported code to check for 
"rogue" svn:externals that are not locked down to a specific revision number.  
If there are "rogue" svn:externals, then you'll need to branch/tag and update 
the svn:externals before doing your build, or reject the code drop until the 
svn:externals are fixed.  Another similar alternative as you've stated, is to 
only allow svn:externals that point to tagged code.

If you want don't want to validate externals on the front end, you can try 
recording the externals after the fact.  If you do a checkout of the code, you 
can cd into each external and get the revision number (via svn info.)  Or you 
could parse the output of "svn co" or "svn export" to get the revision numbers 
of the externals items and record them somewhere.  ("svn update" will also 
return the revision numbers of externals.)  Ex:  Create the tag, run "svn co 
tag", record the revision numbers pulled in, go back and add "-r 123" to the 
svn:externals in the tag branch.  However, I haven't checked how nested 
externals are handled, e.g. your external reference could contain svn:externals 
which could have svn:externals of their own, ad infinitum.

A really simple option is to export the code (including externals) and then 
import the code again as its own tag.  Needless to say this breaks history, but 
it does guarantee that you can reproduce the build.

Using "--ignore-externals" isn't normally practical.

software distribution with subversion

2013-01-31 Thread Jason Keltz 

Hi.

I am faced with a problem where I need to distribute a directory 
containing about 60 GB worth of software on a Linux file server to about 
100 systems.  The software must be localized on those systems and not 
shared out over NFS.  On a regular basis, software may be added or 
removed from the directory, and all the clients should update 
accordingly in the evening.  During the update period, some client 
systems may be off.


I think that Subversion would be a reasonable way to solve this problem 
which isn't quite the type of problem that rsync is intended to handle 
(because of the number of machines).  However, for a variety of reasons, 
I don't want to run subversion on the actual file server.  Instead, 
nightly, I'd like to rsync changes in the contents of the software 
directory on the file server to a software distribution server which 
would run its own svnserve.  The clients would then connect up to the 
server nightly, and update themselves accordingly.  Because of the 
versioning, if a client misses an update, it would be updated the next 
time around, even if its been off for a while.


The inital update between the file server and the software update server 
would require rsyncing the whole 60 GB of software to a "working 
directory", after which, to make subversion see this as a "working 
directory", I would have to commit the entire directory, then check it 
back out.  This process seems like a bit of a waste, but it's a one time 
process, and I don't really see any way around it.  In the future, I 
would like to be able to rsync changes between the file server and the 
working directory on the software distribution server, which would 
including using --delete to ensure that software deleted from the file 
server is also deleted from the subversion working idrectory, and 
including the excluding of the .svn directory from the working copy.  
However, after the rsync happens, I now need to run a command that would 
update the repository with the state of the working directory.  However, 
it's not exactly clear how this would work?  Running an "svn update" 
isn't going to delete directories from the repository that were deleted 
from the working directory.  I believe you need to use "svn delete" for 
this?


Any ideas that anyone might be able to offer?

I'm not on the list, so please ensure that you CC: me in any response.

Thanks for your help!

Jason.

RE: software distribution with subversion

2013-01-31 Thread Bob Archer 

> I am faced with a problem where I need to distribute a directory containing
> about 60 GB worth of software on a Linux file server to about
> 100 systems.  The software must be localized on those systems and not shared
> out over NFS.  On a regular basis, software may be added or removed from the
> directory, and all the clients should update accordingly in the evening.  
> During
> the update period, some client systems may be off.
> 
> I think that Subversion would be a reasonable way to solve this problem which
> isn't quite the type of problem that rsync is intended to handle (because of 
> the
> number of machines).  However, for a variety of reasons, I don't want to run
> subversion on the actual file server.  Instead, nightly, I'd like to rsync 
> changes in
> the contents of the software directory on the file server to a software
> distribution server which would run its own svnserve.  The clients would then
> connect up to the server nightly, and update themselves accordingly.  Because
> of the versioning, if a client misses an update, it would be updated the next
> time around, even if its been off for a while.
> 
> The inital update between the file server and the software update server would
> require rsyncing the whole 60 GB of software to a "working directory", after
> which, to make subversion see this as a "working directory", I would have to
> commit the entire directory, then check it back out.  This process seems like 
> a
> bit of a waste, but it's a one time process, and I don't really see any way 
> around
> it.  In the future, I would like to be able to rsync changes between the file
> server and the working directory on the software distribution server, which
> would including using --delete to ensure that software deleted from the file
> server is also deleted from the subversion working idrectory, and including 
> the
> excluding of the .svn directory from the working copy.
> However, after the rsync happens, I now need to run a command that would
> update the repository with the state of the working directory.  However, it's 
> not
> exactly clear how this would work?  Running an "svn update"
> isn't going to delete directories from the repository that were deleted from 
> the
> working directory.  I believe you need to use "svn delete" for this?
> 
> Any ideas that anyone might be able to offer?
> 
> I'm not on the list, so please ensure that you CC: me in any response.
> 
> Thanks for your help!
> 


What you need to do could work. I assume this "software" in order to run can 
build built or whatever during your nightly update on each client?

You keep saying "rsyncing" ... you wouldn't use that. You wouldn't use that of 
course, you would use the svn client binary.

For you initial load... if the software is on the server where you will house 
your repository you can just import the data into the repository from that 
file... there is no need to send the data twice. In other words, you can have 
both a working copy and a repository on your central server. 

> However, after the rsync happens, I now need to run a command that would
> update the repository with the state of the working directory.  However, it's 
> not
> exactly clear how this would work?  Running an "svn update"

"svn update" brings any changes in the repository to your working copy. "svn 
commit" does the opposite... it puts any changes in a working directory into 
the repository. 

Hth... 

That said, if this is actual software, wouldn't using one of the many package 
management tools available in Linux be a better fit?

BOb

file externals inside directory externals trouble in 1.6 not 1.7 ?

2013-01-31 Thread Ward Willats 
Hello.

I setup some directory and file externs to prune the boost C++ library tree for 
our projects. 

Like this:

http://repo/boost/boost_dir/ boost/boost_dir/
http://repo/boost/boostfile.cpp  boost/boost_file.cpp

(only a lot more complicated)

That is, I used directory externals to create the boost/subdirectories from the 
boost tree in the working copy, and the file externals to pepper the top-level 
boost files into boost/.

Worked great in my 1.7.0 client with new working copy format. Told all my 
co-workers to "come and get it!" Said co-workers are using various 1.6.x 
clients, BUT, while they got the directory externs they got NONE of the file 
externs. (In the case of 1.6.11 -- I think -- it complained the top-level boost 
external was "not a working copy.")

I guess I want to know WTF? -- since the docs say file externs are supported in 
1.6 and up. Was this sort of nesting broken originally? If so, when was it 
fixed? Or is it because I am using the new 1.7 working copy format things are 
good for me?

Thanks

-- Ward

Re: software distribution with subversion

2013-01-31 Thread Branko Čibej 
I expect you've considered this option, but just to add it to the list:
Why not use a package manager like apt or yum, or a distributed
configuration manager such as puppet, to manage your servers?

While Subversion can be used as a substitute, it's not really suited for
this kind of application -- especially if the software has to be
customized for each node.

-- Brane

On 31.01.2013 23:10, Jason Keltz wrote:
> Hi.
>
> I am faced with a problem where I need to distribute a directory
> containing about 60 GB worth of software on a Linux file server to
> about 100 systems.  The software must be localized on those systems
> and not shared out over NFS.  On a regular basis, software may be
> added or removed from the directory, and all the clients should update
> accordingly in the evening.  During the update period, some client
> systems may be off.
>
> I think that Subversion would be a reasonable way to solve this
> problem which isn't quite the type of problem that rsync is intended
> to handle (because of the number of machines).  However, for a variety
> of reasons, I don't want to run subversion on the actual file server. 
> Instead, nightly, I'd like to rsync changes in the contents of the
> software directory on the file server to a software distribution
> server which would run its own svnserve.  The clients would then
> connect up to the server nightly, and update themselves accordingly. 
> Because of the versioning, if a client misses an update, it would be
> updated the next time around, even if its been off for a while.
>
> The inital update between the file server and the software update
> server would require rsyncing the whole 60 GB of software to a
> "working directory", after which, to make subversion see this as a
> "working directory", I would have to commit the entire directory, then
> check it back out.  This process seems like a bit of a waste, but it's
> a one time process, and I don't really see any way around it.  In the
> future, I would like to be able to rsync changes between the file
> server and the working directory on the software distribution server,
> which would including using --delete to ensure that software deleted
> from the file server is also deleted from the subversion working
> idrectory, and including the excluding of the .svn directory from the
> working copy.  However, after the rsync happens, I now need to run a
> command that would update the repository with the state of the working
> directory.  However, it's not exactly clear how this would work? 
> Running an "svn update" isn't going to delete directories from the
> repository that were deleted from the working directory.  I believe
> you need to use "svn delete" for this?
>
> Any ideas that anyone might be able to offer?
>
> I'm not on the list, so please ensure that you CC: me in any response.
>
> Thanks for your help!
>
> Jason.


-- 
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com

Re: software distribution with subversion

2013-01-31 Thread Les Mikesell 
On Thu, Jan 31, 2013 at 4:10 PM, Jason Keltz  wrote:
>
> I am faced with a problem where I need to distribute a directory containing
> about 60 GB worth of software on a Linux file server to about 100 systems.
> The software must be localized on those systems and not shared out over NFS.
> On a regular basis, software may be added or removed from the directory, and
> all the clients should update accordingly in the evening.  During the update
> period, some client systems may be off.
>
> I think that Subversion would be a reasonable way to solve this problem
> which isn't quite the type of problem that rsync is intended to handle
> (because of the number of machines).

I'd think it is exactly the problem that rsync is intended to handle.

> However, for a variety of reasons, I
> don't want to run subversion on the actual file server.  Instead, nightly,
> I'd like to rsync changes in the contents of the software directory on the
> file server to a software distribution server which would run its own
> svnserve.  The clients would then connect up to the server nightly, and
> update themselves accordingly.  Because of the versioning, if a client
> misses an update, it would be updated the next time around, even if its been
> off for a while.

Subversion would give you the option of intentionally maintaining your
targets at different revision levels, but at a cost of needing a
'working copy' format where you have an unneeded 'pristine' duplicate
copy of everything.

> However, after the rsync happens, I now need to run a
> command that would update the repository with the state of the working
> directory.  However, it's not exactly clear how this would work?  Running an
> "svn update" isn't going to delete directories from the repository that were
> deleted from the working directory.

Sure it will - it will make it match the state of whatever version you
are updating to.

> I believe you need to use "svn delete"
> for this?

That is for when you are making the changes you intend to commit.

-- 
  Les Mikesell
 lesmikes...@gmail.com

Re: software distribution with subversion

2013-01-31 Thread Jason Keltz 

On 31/01/2013 6:06 PM, Bob Archer wrote:

I am faced with a problem where I need to distribute a directory containing
about 60 GB worth of software on a Linux file server to about
100 systems.  The software must be localized on those systems and not shared
out over NFS.  On a regular basis, software may be added or removed from the
directory, and all the clients should update accordingly in the evening.  During
the update period, some client systems may be off.

I think that Subversion would be a reasonable way to solve this problem which
isn't quite the type of problem that rsync is intended to handle (because of the
number of machines).  However, for a variety of reasons, I don't want to run
subversion on the actual file server.  Instead, nightly, I'd like to rsync 
changes in
the contents of the software directory on the file server to a software
distribution server which would run its own svnserve.  The clients would then
connect up to the server nightly, and update themselves accordingly.  Because
of the versioning, if a client misses an update, it would be updated the next
time around, even if its been off for a while.

The inital update between the file server and the software update server would
require rsyncing the whole 60 GB of software to a "working directory", after
which, to make subversion see this as a "working directory", I would have to
commit the entire directory, then check it back out.  This process seems like a
bit of a waste, but it's a one time process, and I don't really see any way 
around
it.  In the future, I would like to be able to rsync changes between the file
server and the working directory on the software distribution server, which
would including using --delete to ensure that software deleted from the file
server is also deleted from the subversion working idrectory, and including the
excluding of the .svn directory from the working copy.
However, after the rsync happens, I now need to run a command that would
update the repository with the state of the working directory.  However, it's 
not
exactly clear how this would work?  Running an "svn update"
isn't going to delete directories from the repository that were deleted from the
working directory.  I believe you need to use "svn delete" for this?

Any ideas that anyone might be able to offer?

I'm not on the list, so please ensure that you CC: me in any response.

Thanks for your help!



What you need to do could work. I assume this "software" in order to run can 
build built or whatever during your nightly update on each client?

You keep saying "rsyncing" ... you wouldn't use that. You wouldn't use that of 
course, you would use the svn client binary.

Actually, maybe I wasn't clear..
The software includes various packages like say, Matlab, or Maple, or 
whatever else, already installed...  imagine a directory on the 
fileserver.. say, /local/software which includes "bin", "lib", etc...
I'm not "installing" the software.   it's already been installed..  I'm 
just syncing a directory between machines..
As for rsyncing.. I would rsync the software from the "file server" to 
the "software distribution" server, and then use svn from there to check 
in all the changes.



For you initial load... if the software is on the server where you will house 
your repository you can just import the data into the repository from that 
file... there is no need to send the data twice. In other words, you can have 
both a working copy and a repository on your central server.
Yes.  Initially I would do an import, but the problem is... the next 
day, the software gets updated on the "real" file server... say, new 
version of Matlab or something...  in the evening, I want the process to 
run that would rsync the data (with all the changes) from the file 
server to the software distribution server,  do something to commit the 
changes, then the 100 clients would eventually each "svn update". 
However, to be able to commit the changes, I need to have a working copy 
on the software distribution server



However, after the rsync happens, I now need to run a command that would
update the repository with the state of the working directory.  However, it's 
not
exactly clear how this would work?  Running an "svn update"

"svn update" brings any changes in the repository to your working copy. "svn 
commit" does the opposite... it puts any changes in a working directory into the repository.
See, this is where I'm confused... I created a few directories including 
"bin" and "pkg" for a test.  All committed fine... erased them from the 
working copy, did a commit then a status and I see:


!   bin
!   pkg

but when I go into a different directory and check out the current state..

Apkg
Abin
Checked out revision 2.

they're still there...


Hth...

That said, if this is actual software, wouldn't using one of the many package 
management tools available in Linux be a better fit?


The thing is, I'm moving around already i

Re: software distribution with subversion

2013-01-31 Thread Ryan Schmidt 

On Jan 31, 2013, at 20:05, Jason Keltz wrote:

> On 31/01/2013 6:06 PM, Bob Archer wrote:
>> 
>> What you need to do could work. I assume this "software" in order to run can 
>> build built or whatever during your nightly update on each client?
>> 
>> You keep saying "rsyncing" ... you wouldn't use that. You wouldn't use that 
>> of course, you would use the svn client binary.
> Actually, maybe I wasn't clear..
> The software includes various packages like say, Matlab, or Maple, or 
> whatever else, already installed...  imagine a directory on the fileserver.. 
> say, /local/software which includes "bin", "lib", etc...I'm not 
> "installing" the software.   it's already been installed..  I'm just syncing 
> a directory between machines..
> As for rsyncing.. I would rsync the software from the "file server" to the 
> "software distribution" server, and then use svn from there to check in all 
> the changes.
> 
>> For you initial load... if the software is on the server where you will 
>> house your repository you can just import the data into the repository from 
>> that file... there is no need to send the data twice. In other words, you 
>> can have both a working copy and a repository on your central server.
> Yes.  Initially I would do an import, but the problem is... the next day, the 
> software gets updated on the "real" file server... say, new version of Matlab 
> or something...  in the evening, I want the process to run that would rsync 
> the data (with all the changes) from the file server to the software 
> distribution server,  do something to commit the changes, then the 100 
> clients would eventually each "svn update". However, to be able to commit 
> the changes, I need to have a working copy on the software distribution 
> server
> 
>>> However, after the rsync happens, I now need to run a command that would
>>> update the repository with the state of the working directory.  However, 
>>> it's not
>>> exactly clear how this would work?  Running an "svn update"
>> "svn update" brings any changes in the repository to your working copy. "svn 
>> commit" does the opposite... it puts any changes in a working directory into 
>> the repository.
> See, this is where I'm confused... I created a few directories including 
> "bin" and "pkg" for a test.  All committed fine... erased them from the 
> working copy, did a commit then a status and I see:
> 
> !   bin
> !   pkg
> 
> but when I go into a different directory and check out the current state..
> 
> Apkg
> Abin
> Checked out revision 2.
> 
> they're still there...

Correct. Subversion does not track your movements. You must tell Subversion 
what you are moving and deleting by doing the moves and deletes using "svn mv" 
and "svn rm", not using regular OS commands.


>> Hth...
>> 
>> That said, if this is actual software, wouldn't using one of the many 
>> package management tools available in Linux be a better fit?
> 
> The thing is, I'm moving around already installed software, and there's 
> nothing that great, as far as I can see, for doing that. The twitter guys are 
> using something they wrote called "murder" which uses torrent to do this kind 
> of thing...  excellent idea, but it uses Ruby and several other tools ...   
> and I don't want to get into that at the moment...

Subversion is not going to be a satisfactory solution for this use case. 
Besides all the issues you're describing with setting up the server-side 
infrastructure for this, and as was already mentioned, when you check out a 
working copy of this on your clients, there will be a "duplicate" pristine copy 
of everything. So if you have 60GB of software, it'll take up 120GB of space on 
the client machine.

Subversion is not a software distribution tool; it is a document and revision 
management system. Use a different tool. As someone else said, rsync seems like 
a good tool for this job; I didn't understand why you think using rsync 
directly between your file server and your clients won't work.

Re: software distribution with subversion

2013-01-31 Thread Jason Keltz 

On 31/01/2013 6:40 PM, Les Mikesell wrote:

On Thu, Jan 31, 2013 at 4:10 PM, Jason Keltz  wrote:

I am faced with a problem where I need to distribute a directory containing
about 60 GB worth of software on a Linux file server to about 100 systems.
The software must be localized on those systems and not shared out over NFS.
On a regular basis, software may be added or removed from the directory, and
all the clients should update accordingly in the evening.  During the update
period, some client systems may be off.

I think that Subversion would be a reasonable way to solve this problem
which isn't quite the type of problem that rsync is intended to handle
(because of the number of machines).

I'd think it is exactly the problem that rsync is intended to handle.
rsync is great when you want to sync the contents from one machine to 
another machine in one direction.. (unison if you need dual direction 
sync...)   I thought about using rsync to solve this problem... two 
ways I can think of..


1)  All the machines run rsync against the server.. kills the server, 
but let's say they do it all at different times.. the server is hefty..  
hey, it would work, but for every single rsync, the server needs to look 
at its entire file tree to see which files have changed 100 syncs = 
100 times processing the same thing over and over again... If only rsync 
would let me save that state to a file so that it doesn't need to reload 
it every time it runs, then I know which solution I'd be using...  other 
problem is, it would take a long time..
2) log/tree approach --- server updates one client, then the server and 
the one client each update another client, then each of those 3 update 
another...  much faster, but again, you have to read the server state 
each and every time... and then I have to deal with the fact that 
various random machines are off ...


It's a really interesting problem..


However, for a variety of reasons, I
don't want to run subversion on the actual file server.  Instead, nightly,
I'd like to rsync changes in the contents of the software directory on the
file server to a software distribution server which would run its own
svnserve.  The clients would then connect up to the server nightly, and
update themselves accordingly.  Because of the versioning, if a client
misses an update, it would be updated the next time around, even if its been
off for a while.

Subversion would give you the option of intentionally maintaining your
targets at different revision levels, but at a cost of needing a
'working copy' format where you have an unneeded 'pristine' duplicate
copy of everything.
The truth is, I wouldn't intentionally have the machines at different 
software levels... (well, that could be useful for testing, but that's 
another story)  but a machine could be off during the update and 
would be able to "catch up" no longer how long it was off...

However, after the rsync happens, I now need to run a
command that would update the repository with the state of the working
directory.  However, it's not exactly clear how this would work?  Running an
"svn update" isn't going to delete directories from the repository that were
deleted from the working directory.

Sure it will - it will make it match the state of whatever version you
are updating to.


I believe you need to use "svn delete"
for this?

That is for when you are making the changes you intend to commit.



I'll have to try that again .. didn't seem to be working the way I 
expected it to...


Jason.


--
Jason Keltz
Manager of Development
Department of Computer Science and Engineering
York University, Toronto, Canada
Tel: 416-736-2100 x. 33570
Fax: 416-736-5872

Re: software distribution with subversion

2013-01-31 Thread Jason Keltz 

On 31/01/2013 9:13 PM, Ryan Schmidt wrote:

On Jan 31, 2013, at 20:05, Jason Keltz wrote:


On 31/01/2013 6:06 PM, Bob Archer wrote:

What you need to do could work. I assume this "software" in order to run can 
build built or whatever during your nightly update on each client?

You keep saying "rsyncing" ... you wouldn't use that. You wouldn't use that of 
course, you would use the svn client binary.

Actually, maybe I wasn't clear..
The software includes various packages like say, Matlab, or Maple, or whatever else, already installed...  
imagine a directory on the fileserver.. say, /local/software which includes "bin", "lib", 
etc...I'm not "installing" the software.   it's already been installed..  I'm just syncing a 
directory between machines..
As for rsyncing.. I would rsync the software from the "file server" to the "software 
distribution" server, and then use svn from there to check in all the changes.


For you initial load... if the software is on the server where you will house 
your repository you can just import the data into the repository from that 
file... there is no need to send the data twice. In other words, you can have 
both a working copy and a repository on your central server.

Yes.  Initially I would do an import, but the problem is... the next day, the software gets updated 
on the "real" file server... say, new version of Matlab or something...  in the evening, 
I want the process to run that would rsync the data (with all the changes) from the file server to 
the software distribution server,  do something to commit the changes, then the 100 clients would 
eventually each "svn update". However, to be able to commit the changes, I need to 
have a working copy on the software distribution server


However, after the rsync happens, I now need to run a command that would
update the repository with the state of the working directory.  However, it's 
not
exactly clear how this would work?  Running an "svn update"

"svn update" brings any changes in the repository to your working copy. "svn 
commit" does the opposite... it puts any changes in a working directory into the repository.

See, this is where I'm confused... I created a few directories including "bin" and 
"pkg" for a test.  All committed fine... erased them from the working copy, did a commit 
then a status and I see:

!   bin
!   pkg

but when I go into a different directory and check out the current state..

Apkg
Abin
Checked out revision 2.

they're still there...

Correct. Subversion does not track your movements. You must tell Subversion what you are moving and 
deleting by doing the moves and deletes using "svn mv" and "svn rm", not using 
regular OS commands.



Hth...

That said, if this is actual software, wouldn't using one of the many package 
management tools available in Linux be a better fit?

The thing is, I'm moving around already installed software, and there's nothing that 
great, as far as I can see, for doing that. The twitter guys are using something they 
wrote called "murder" which uses torrent to do this kind of thing...  excellent 
idea, but it uses Ruby and several other tools ...   and I don't want to get into that at 
the moment...

Subversion is not going to be a satisfactory solution for this use case. Besides all the 
issues you're describing with setting up the server-side infrastructure for this, and as 
was already mentioned, when you check out a working copy of this on your clients, there 
will be a "duplicate" pristine copy of everything. So if you have 60GB of 
software, it'll take up 120GB of space on the client machine.

I'm glad you brought that up :)


Subversion is not a software distribution tool; it is a document and revision 
management system. Use a different tool. As someone else said, rsync seems like 
a good tool for this job; I didn't understand why you think using rsync 
directly between your file server and your clients won't work.



See my email to Les...  If only the rsync server could save a copy of 
the file checksums when it runs, it would probably decrease the sync 
time by half and save a whole lot of disk activity...



--
Jason Keltz
Manager of Development
Department of Computer Science and Engineering
York University, Toronto, Canada
Tel: 416-736-2100 x. 33570
Fax: 416-736-5872

Re: software distribution with subversion

2013-01-31 Thread Nico Kadel-Garcia 
On Thu, Jan 31, 2013 at 9:18 PM, Jason Keltz  wrote:
> On 31/01/2013 9:13 PM, Ryan Schmidt wrote:

>> Subversion is not a software distribution tool; it is a document and
>> revision management system. Use a different tool. As someone else said,
>> rsync seems like a good tool for this job; I didn't understand why you think
>> using rsync directly between your file server and your clients won't work.
>>
>
> See my email to Les...  If only the rsync server could save a copy of the
> file checksums when it runs, it would probably decrease the sync time by
> half and save a whole lot of disk activity...

This sounds like somone wants to use the same screwdriver for all
screws in this birdhouse.

It's theoretically possible to set a canonical Subversion and
auto-propagate changes to it, from the "file server" or from the an
rsynced copy of the fileserver with a local working copy on the
Subversion master. But it's going to be bulky, and slow. If that 60
GBytes has a lot of churn due to rapidly changing binaries or
extensive static database files, it's going to get awkward indeed. And
because the "file server" you're propagating these changes from is
neither a Subversion server, nor a Subversion client, it's much
harder. Moreover, this doesn't seem to be the kind of "rollback the
changes to a well-defined date" that Subversion does so well,a nd the
changes from the master get fed to a trunk and will then have to be
propagated to branches., and each machine will need a different
branch.

This gets tricky. One can differentiate among the slightly
different environments by maintaining a trunk and merging the changes
to the branches, but that can get awkward. Is it possible to set up
tags that haven "svn:external" settings that point to sets of software
from the master, and then the individual hosts are configured locally
and have their changes propagated to the branches on the master?

And you know, this sounds like an absolute flipping deployment
disaster I dealt with about 12 years ago. The site architect thought
the clever thing to do was make a complete tarball bundle for all
deployments, and the whole compressed tarball had to be pushed *every
time*, and releases could only happen with the complete tarball.
Various forms of chaos ensued. I taught them to use packages, to
deploy kernels, in particular, as a separate object so they could be
deployed separately and with rollback separate from the rest of the
system. This fixed the ongoing problem that any one component that
failed would stop the *whole* deployment and push back even the
smallest fixes for as much as six months.

So while I've offered some hints, I'm gong to really suggest to Jason
that he think hard about modularizing the components of this set of
packages before he even starts this project.

Apache Subversion 1.7.7 - svn log issues

2013-01-31 Thread Ramachandran Raghavendran 
Hi, 

 

I performed the very first commit into a repository and I'm running the
svn log command at the file level (svn log -v --xml --stop-on-copy @URL
PATH, where PATH  represents a file). 

However this syntax  lists all the changes to the URL.

Have anybody encountered this behaviour . is this a  bug?

 

 

Best regards,

 

Ramachandran Raghavendran

Re: software distribution with subversion

2013-01-31 Thread Les Mikesell 
On Thu, Jan 31, 2013 at 8:14 PM, Jason Keltz  wrote:
>>
>> I'd think it is exactly the problem that rsync is intended to handle.
>
> rsync is great when you want to sync the contents from one machine to
> another machine in one direction.. (unison if you need dual direction
> sync...)   I thought about using rsync to solve this problem... two ways
> I can think of..
>
> 1)  All the machines run rsync against the server.. kills the server, but
> let's say they do it all at different times.. the server is hefty..  hey, it
> would work, but for every single rsync, the server needs to look at its
> entire file tree to see which files have changed 100 syncs = 100 times
> processing the same thing over and over again... If only rsync would let me
> save that state to a file so that it doesn't need to reload it every time it
> runs, then I know which solution I'd be using...  other problem is, it would
> take a long time..

Is this on linux?  If the host has a reasonable amount of RAM the
directory info will mostly be cached between accesses. Have you timed
it before deciding it is a problem?  I suspect it won't be unless
there are millions of small files in that tree or a very fast rate of
change.

> 2) log/tree approach --- server updates one client, then the server and the
> one client each update another client, then each of those 3 update
> another...  much faster, but again, you have to read the server state each
> and every time... and then I have to deal with the fact that various random
> machines are off ...

If you can't complete from one distribution server - or if the
geographic location makes sense, fan it out to a few redistribution
instances.   Not sure what you mean about reading server state -
directory reads aren't all that expensive.

>> Subversion would give you the option of intentionally maintaining your
>> targets at different revision levels, but at a cost of needing a
>> 'working copy' format where you have an unneeded 'pristine' duplicate
>> copy of everything.
>
> The truth is, I wouldn't intentionally have the machines at different
> software levels... (well, that could be useful for testing, but that's
> another story)  but a machine could be off during the update and would
> be able to "catch up" no longer how long it was off...

Rsync would always catch up.  If the exact refresh timing isn't
critical you could just run from cron on the clients with some skew to
avoid overloading the distribution server.

>>> I believe you need to use "svn delete"
>>> for this?
>>
>> That is for when you are making the changes you intend to commit.
>>
>
> I'll have to try that again .. didn't seem to be working the way I expected
> it to...

You have to 'svn delete'  in the working copy, then commit the change,
then an update will replicate the action in another working copy.

-- 
   Les Mikesell
  lesmikes...@gmail.com

Re: software distribution with subversion

2013-01-31 Thread Les Mikesell 
On Thu, Jan 31, 2013 at 8:18 PM, Jason Keltz  wrote:
> >
> See my email to Les...  If only the rsync server could save a copy of the
> file checksums when it runs, it would probably decrease the sync time by
> half and save a whole lot of disk activity...

If you don't use the --ignore-times option with rsync it will skip the
checksum comparison on files where the timestamp, length, etc. match.
It should only have to read the directory on both sides if nothing
changes between runs.   Be sure you are using options that propagate
the timestamp (like -a) for this to work.

-- 
   Les Mikesell
 lesmikes...@gmail.com

Re: Unable to login

2013-01-31 Thread vishwajeet singh 
On Fri, Feb 1, 2013 at 11:28 AM, Navneet Kanwat <
navne...@sumtotalsystems.com> wrote:

>  Hi,
>
>
>
> I was confused with my svn username and password. I was not aware that if
> I put them wrong It’ll start showing exceptions. Please suggest me the next
> step. I tried entering the link
> https://app.codesion.com/ajax#login?domain=trilogy . It’s output is
> attached with this mail.
>

Url which you are using does not seems to be a valid repository url, that
looks like a login url to web application.


>
>
> Thanks,
>  --
>
> *Navneet Kanwat*
>
> [image: Description: Description: Description:
> http://www.sumtotalsystems.com/email/sumtlogo_2009.gif]
>
> *Software Design Engineer II*
>
> *SumTotal Systems, Inc.*
>
> Mobile: +91 77999184056
>
> Phone:  3525193409
>
> www.sumtotalsystems.com
>
> [image: 
> http://www.sumtotalsystems.com/email/campaighn_blurb_offer3.gif]
>
>
>
>
> This message and any attachments thereto contain information that may
> be privileged, confidential or otherwise protected from disclosure and is
> the property of SumTotal Systems, Inc.  It is intended only for the person
> to whom it is addressed.  If you are not the intended recipient, you are
> not authorized to read, print, retain, copy, disseminate, distribute, or
> use this message, any attachments thereto or any part thereof.  If you
> receive this message in error, please notify me at
> navne...@sumtotalsystems.com and delete all copies of this message and
> attachments.   SumTotal Systems, Inc. has implemented anti-virus software
> on its computers and servers, however, it is the recipient's own
> responsibility to ensure that all attachments are scanned for viruses prior
> to usage.
>



-- 
Vishwajeet Singh
+91-9657702154 | dextrou...@gmail.com | http://bootstraptoday.com
Twitter: http://twitter.com/vishwajeets | LinkedIn:
http://www.linkedin.com/in/singhvishwajeet
<><>

Re: Unable to login

2013-01-31 Thread Jeyanthan I 


On Friday 01 February 2013 11:28 AM, Navneet Kanwat wrote:

Hi,

I was confused with my svn username and password. I was not aware that
if I put them wrong It’ll start showing exceptions. Please suggest me
the next step. I tried entering the link
https://app.codesion.com/ajax#login?domain=trilogy . It’s output is
attached with this mail.



Hi Navneet,

It looks like you have issues with your account credentials. Did you try 
Forgot Password link to reset your password?


As I see you use Codesion service, you might have to raise a ticket here 
to seek assistance from Cloudforge folks.


https://help.cloudforge.com/

--
Regards,
Jeyanthan