Re: Branch/switch/merge question

2013-11-27 Thread Les Mikesell
On Tue, Nov 26, 2013 at 8:02 PM, Edward Ned Harvey (svn4)
 wrote:
>
>
> At first, I was doing a sparse checkout.  I non-recursively checked out /, 
> and then I made /trunk fully recursive, and then I went one level deeper into 
> /branches, and then I made /branches/eharvey fully recursive...  And then I 
> discovered how natural it was to switch & merge, so I got rid of my whole 
> working copy, and re-checked out recursively (non-sparse) /trunk.  But it 
> sounds like you suggest going back to the non-recursive checkout of /, with 
> recursive /trunk, and recursive /branches/eharvey.

Not sure what you mean about with sparse and recursive checkouts or
why you'd start with /.   If there is one project in the repository
you would normally just check out /trunk.  Or with multiple projects,
/project_name/trunk.

> Just to keep the branch & trunk logically separate from each other and 
> eliminate any user error regarding "Which what, oh, where am I?  I forget..." 
>   You might be right...  and if I say so to the other guys, they might use 
> this to bludgeon me into git.   ;-)

You can have multiple checkouts that don't really affect each other,
so yes sometimes it is simpler to just have a parallel checkout of a
branch unless there are bandwidth or disk space constraints that make
switching more efficient.

If your project is large enough to split out libraries that can be
developed separately, consider moving them out to project-level
directories or separate repositories, and assembling the components
you want in the main project with svn externals.   Then each component
can have its own release scheduling (make tags, then when a project
using the component wants to update, change the external to the newer
tag).  This lets your team work on different parts without too much
impact on each other while still being able to build the whole thing
easily.

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


Re: Hardware requirements for windows subversion

2013-11-27 Thread Ram
Thank you all for your help.



--
View this message in context: 
http://subversion.1072662.n5.nabble.com/Hardware-requirements-for-windows-subversion-tp185979p186007.html
Sent from the Subversion Users mailing list archive at Nabble.com.


Re: wc.db: corruption after move?

2013-11-27 Thread Marc Strapetz
On 27.11.2013 11:32, Bert Huijben wrote:
> 
> 
>> -Original Message-
>> From: Marc Strapetz [mailto:marc.strap...@syntevo.com]
>> Sent: woensdag 27 november 2013 09:30
>> To: Philip Martin
>> Cc: Branko Čibej; users@subversion.apache.org
>> Subject: Re: wc.db: corruption after move?
>>
>> On 26.11.2013 21:38, Philip Martin wrote:
>>> Marc Strapetz  writes:
>>>
>>> As far as I have been told, this has already been fixed and backported
>>> to 1.8.5. Still, for those users which already have this corruption, is
>>> there a way to recover their working copies with standard Subversion
>>> functionality? Could a Revert work? And if it currently does not, could
>>> the Revert be more tolerant, so it could handle such cases?
>> What operation is failing?  Are you getting some error?

 I can't tell whether an operation fails, because an assertion when
 reading the wc.db is hit before. I'd expect some operations (in the GUI)
 to fail later, because we are assuming at various places that a moved
 file must have a move-source. Is this assumption correct?
>>>
>>> Is that Subversion that is asserting?  It would help if you showed the
>>> exact error or assertion.
>>
>> It's an assertion in SmartSVN which directly reads wc.db.
>>
>>> If moved_to is missing Subversion usually falls back to copy and delete:
>>
>> OK, so it's a valid wc.db state? I think that answers my question and I
>> will fix/remove SmartSVN's assertion accordingly.
> 
> No, this is not a valid state. But we prefer to fix the problem how you got 
> there, over updating Subversion to cope with invalid states everywhere.

Unfortunately the user who has encountered this problem doesn't know
(anymore) how he came into that state.

-Marc


Re: Hardware requirements for windows subversion

2013-11-27 Thread Pavel Lyalyakin
Hello Ram,

> Thank you for your response. I have a .net site the file size is 2 GB.
> There are only 2 developers working on this project remotely. Do I need
> windows server or windows 7? What kind of hardware, RAM, diskspace do I
> need? Do I still need Apache server? Where can i get Subversion installation
> from? Do I need to install visualSVN or serveSVN? You wrote that configuring
> the encryption takes a lot more complexity, is there any step-by-step
> instructions on that? What do you mean by serial processing? I don't have
> more than one cpu available.

As Edward already said: "If you can run windows, you can run svn".
Machine specs can matter for larger installations with numerous
developers accessing the same server, but that's definitely not your
case. Only 2 developers accessing just one repository won't cause any
significant load on the minimal machine capable of running Windows 7.

If you want to start using Subversion server right now, then take a
closer look at VisualSVN Server. It installs in no time and is very
convenient to configure and manage. In fact, VisualSVN Server works
out of the box and does *not* require you to bother with complex
configuration. You can get the latest VisualSVN Server version at
http://www.visualsvn.com/server/download/

Thank you.

--
With best regards,
Pavel Lyalyakin
VisualSVN Team


RE: Hardware requirements for windows subversion

2013-11-27 Thread Ram
Hi Edward,
Thank you for your response. I have a .net site the file size is 2 GB.
There are only 2 developers working on this project remotely. Do I need
windows server or windows 7? What kind of hardware, RAM, diskspace do I
need? Do I still need Apache server? Where can i get Subversion installation
from? Do I need to install visualSVN or serveSVN? You wrote that configuring
the encryption takes a lot more complexity, is there any step-by-step
instructions on that? What do you mean by serial processing? I don't have
more than one cpu available.

Your help is greatly appreciated,
Ram



--
View this message in context: 
http://subversion.1072662.n5.nabble.com/Hardware-requirements-for-windows-subversion-tp185979p185998.html
Sent from the Subversion Users mailing list archive at Nabble.com.


RE: SVN lock at version 1.8.3 and 1.8.4 - not working

2013-11-27 Thread Kovar, Vaclav (EOM)
>If your script really has 'echo off' and not '@echo off' then your script 
>produces output. And you should check the documentation on how that is handled 
>for the specific hooks. For pre-lock this has side effects:
>[[
># If the hook program outputs anything on stdout, the output string will # be 
>used as the lock token for this lock operation.  If you choose to use # this 
>feature, you must guarantee the tokens generated are unique across # the 
>repository each >time.
>]]

Sorry, my mistake, you are correct.  I corrected it to " @echo off".

I tested  it 5 minutes ago, same result for either "@echo off" or "echo off":

- during commit all 3 hooks are executed, commit is successfull
- during lock no hook is executed, lock failed



> What operation did you perform to test the lock hook?
> svn lock ?
> The lock script is invoked as part of committing.

Yes. I used testing SVN instance on my machine, so SVN bin is not on the PATH.

Copied/pasted:


C:\work\dzcvk82\svn_views\test6\test001>dir

 Výpis adresáře C:\work\dzcvk82\svn_views\test6\test001

27.11.2013  15:05  .
27.11.2013  15:05  ..
27.11.2013  15:05   135 testfile.txt
   Souborů:  1,   Bajtů:135
   Adresářů: 2,   Volných bajtů:  6 574 776 320

C:\work\dzcvk82\svn_views\test6\test001>c:\software\Subversion\bin\svn.exe lock 
testfile.txt
svn: E200035: sqlite[S19]: LOCK.lock_token may not be NULL
svn: E200035: Additional errors:
svn: E200035: sqlite[S19]: LOCK.lock_token may not be NULL

C:\work\dzcvk82\svn_views\test6\test001>



Perhaps the the lock fails before the hook execution.

Vena Kovar


Re: Can't access SVN repos from command Line: Server SSL certificate untrusted

2013-11-27 Thread Daniel Shahaf
Edward Ned Harvey (svn4) wrote on Wed, Nov 27, 2013 at 01:47:11 +:
> What are the important details and/or original post that I'm missing?

You could read the original post in the list archives...

http://svn.haxx.se/users/archive-2013-11/


RE: Hardware requirements for windows subversion

2013-11-27 Thread Edward Ned Harvey (svn4)
> From: Ram [mailto:house4rent...@yahoo.com]
> Sent: Tuesday, November 26, 2013 7:33 PM
> 
> Hello,
> I am looking to use subversion for .Net applications. What type of
> hardware do I need? What version of windows server, RAM, hard disk space
> do
> I need?

If you can run windows, you can run svn.  But to qualify that a little more:  I 
presume you're asking about server requirements (not client requirements.)  I 
recommend using svnserve (I believe collabnet distributes a simple installation 
package) I recommend svnserve if all your access will be from an internal 
private LAN and you don't need per-folder ACL's and so forth.  svnserve is very 
lightweight and fast, very easy to install and configure, but it's 
non-encrypted so I wouldn't recommend facing it to the internet.  If you need 
to face the internet, you're probably going to need to run apache and https (or 
svn+ssh, but I think apache https is better)...  Configuring the encryption and 
all takes a lot more complexity.  So you really just need to spec your server 
as if it were a web server.

Be aware, sometimes svn will need to do a long time serial processing.  So it's 
advantageous for you to have more than one CPU core.


RE: SVN lock at version 1.8.3 and 1.8.4 - not working

2013-11-27 Thread Bert Huijben


> -Original Message-
> From: Kovar, Vaclav (EOM) [mailto:vaclav.ko...@skoda-auto.cz]
> Sent: woensdag 27 november 2013 13:10
> To: users@subversion.apache.org
> Subject: RE: SVN lock at version 1.8.3 and 1.8.4 - not working
> 
> >What output does your 'pre-lock' hook template produce?
> >My guess would be that it produces something...
> 
> Hello,
> My repo hasnt any active hooks, just templates in  hooks dir.
> So as first i tried to run almost empty pre-lock hook and strange is, the
batch
> file is not executed. Next step was to verify other hooks. Commit hooks
was
> started successfully, but lock hook not.
> 
> Details:
> My (very simple) hook batch (for start-commit, pre-commit and post-commit
> are similar):
> 
> pre-lock.bat
> 
> echo off

If your script really has 'echo off' and not '@echo off' then your script
produces output. And you should check the documentation on how that is
handled for the specific hooks. For pre-lock this has side effects:
[[
# If the hook program outputs anything on stdout, the output string will
# be used as the lock token for this lock operation.  If you choose to use
# this feature, you must guarantee the tokens generated are unique across
# the repository each time.
]]

> 
> echo begin pre-lock >>
> C:\software\svnroot\repos\test001\hooks\tracefile.txt
> echo SVN_REPOS %1 >>
> C:\software\svnroot\repos\test001\hooks\tracefile.txt
> echo SVN_PATH %2 >>
> C:\software\svnroot\repos\test001\hooks\tracefile.txt
> echo SVN_USER %3 >>
> C:\software\svnroot\repos\test001\hooks\tracefile.txt
> echo end pre-lock >> C:\software\svnroot\repos\test001\hooks\tracefile.txt
> 
> 
> And tracefile.txt:
> 
> begin start-commit
> REPOS C:\software\svnroot\repos\test001
> USER iras24
> end start-commit
> begin pre-commit
> REPOS C:\software\svnroot\repos\test001
> TXN 4-5
> end pre-commit
> begin post-commit
> REPOS C:\software\svnroot\repos\test001
> REV 5
> TXN_NAME 4-5
> end post-commit
> 
> Eq, no lock hook is executed.
> 
> Please, any recommendations?

What operation did you perform to test the lock hook?

svn lock ?

The lock script is invoked as part of committing.

Bert



RE: SVN lock at version 1.8.3 and 1.8.4 - not working

2013-11-27 Thread Kovar, Vaclav (EOM)
>What output does your 'pre-lock' hook template produce?
>My guess would be that it produces something...

Hello,
My repo hasnt any active hooks, just templates in  hooks dir.
So as first i tried to run almost empty pre-lock hook and strange is, the batch 
file is not executed. Next step was to verify other hooks. Commit hooks was 
started successfully, but lock hook not.

Details:
My (very simple) hook batch (for start-commit, pre-commit and post-commit are 
similar):

pre-lock.bat

echo off

echo begin pre-lock >> C:\software\svnroot\repos\test001\hooks\tracefile.txt
echo SVN_REPOS %1 >> C:\software\svnroot\repos\test001\hooks\tracefile.txt
echo SVN_PATH %2 >> C:\software\svnroot\repos\test001\hooks\tracefile.txt
echo SVN_USER %3 >> C:\software\svnroot\repos\test001\hooks\tracefile.txt
echo end pre-lock >> C:\software\svnroot\repos\test001\hooks\tracefile.txt


And tracefile.txt:

begin start-commit 
REPOS C:\software\svnroot\repos\test001 
USER iras24 
end start-commit 
begin pre-commit 
REPOS C:\software\svnroot\repos\test001 
TXN 4-5 
end pre-commit 
begin post-commit 
REPOS C:\software\svnroot\repos\test001 
REV 5 
TXN_NAME 4-5 
end post-commit

Eq, no lock hook is executed.

Please, any recommendations?


RE: wc.db: corruption after move?

2013-11-27 Thread Bert Huijben


> -Original Message-
> From: Marc Strapetz [mailto:marc.strap...@syntevo.com]
> Sent: woensdag 27 november 2013 09:30
> To: Philip Martin
> Cc: Branko Čibej; users@subversion.apache.org
> Subject: Re: wc.db: corruption after move?
> 
> On 26.11.2013 21:38, Philip Martin wrote:
> > Marc Strapetz  writes:
> >
> > As far as I have been told, this has already been fixed and backported
> > to 1.8.5. Still, for those users which already have this corruption, is
> > there a way to recover their working copies with standard Subversion
> > functionality? Could a Revert work? And if it currently does not, could
> > the Revert be more tolerant, so it could handle such cases?
>  What operation is failing?  Are you getting some error?
> >>
> >> I can't tell whether an operation fails, because an assertion when
> >> reading the wc.db is hit before. I'd expect some operations (in the GUI)
> >> to fail later, because we are assuming at various places that a moved
> >> file must have a move-source. Is this assumption correct?
> >
> > Is that Subversion that is asserting?  It would help if you showed the
> > exact error or assertion.
> 
> It's an assertion in SmartSVN which directly reads wc.db.
> 
> > If moved_to is missing Subversion usually falls back to copy and delete:
> 
> OK, so it's a valid wc.db state? I think that answers my question and I
> will fix/remove SmartSVN's assertion accordingly.

No, this is not a valid state. But we prefer to fix the problem how you got 
there, over updating Subversion to cope with invalid states everywhere.

That is why we asked for a reproduction recipe on how you got the working copy 
in this state.

(I think you can find a few of those in new test cases for fixes nominated for 
backport for 1.8.6)

Bert
> 
> > $ svnadmin create repo
> > $ svn import -mm repo/format file://`pwd`/repo/A/f
> > $ svn co file://`pwd`/repo wc
> > $ svn wc/A wc/B
> > $ svn mv wc/B/f wc/B/g
> >
> > $ svn st wc
> > D   wc/A
> > > moved to wc/B
> > D   wc/A/f
> > A  +wc/B
> > > moved from wc/A
> > D  +wc/B/f
> > > moved to wc/B/g
> > A  +wc/B/g
> > > moved from wc/B/f
> >
> > $ sqlite3 wc/.svn/wc.db "update nodes set moved_to = null"
> > $ svn st wc
> > D   wc/A
> > D   wc/A/f
> > A  +wc/B
> > D  +wc/B/f
> > A  +wc/B/g
> 
> -Marc




Re: wc.db: corruption after move?

2013-11-27 Thread Marc Strapetz
On 26.11.2013 21:38, Philip Martin wrote:
> Marc Strapetz  writes:
> 
> As far as I have been told, this has already been fixed and backported
> to 1.8.5. Still, for those users which already have this corruption, is
> there a way to recover their working copies with standard Subversion
> functionality? Could a Revert work? And if it currently does not, could
> the Revert be more tolerant, so it could handle such cases?
 What operation is failing?  Are you getting some error?
>>
>> I can't tell whether an operation fails, because an assertion when
>> reading the wc.db is hit before. I'd expect some operations (in the GUI)
>> to fail later, because we are assuming at various places that a moved
>> file must have a move-source. Is this assumption correct?
> 
> Is that Subversion that is asserting?  It would help if you showed the
> exact error or assertion.

It's an assertion in SmartSVN which directly reads wc.db.

> If moved_to is missing Subversion usually falls back to copy and delete:

OK, so it's a valid wc.db state? I think that answers my question and I
will fix/remove SmartSVN's assertion accordingly.

> $ svnadmin create repo
> $ svn import -mm repo/format file://`pwd`/repo/A/f
> $ svn co file://`pwd`/repo wc
> $ svn wc/A wc/B
> $ svn mv wc/B/f wc/B/g
> 
> $ svn st wc
> D   wc/A
> > moved to wc/B
> D   wc/A/f
> A  +wc/B
> > moved from wc/A
> D  +wc/B/f
> > moved to wc/B/g
> A  +wc/B/g
> > moved from wc/B/f
> 
> $ sqlite3 wc/.svn/wc.db "update nodes set moved_to = null"
> $ svn st wc
> D   wc/A
> D   wc/A/f
> A  +wc/B
> D  +wc/B/f
> A  +wc/B/g

-Marc