from:"Varnau, Steve \(Neoview\)"

RE: Possible bug in svn's gnome-keyring support?

2010-07-13 Thread Varnau, Steve (Neoview)

Jeremy,

If svn is configured to use a Gnome keyring, then it is trying to store the 
password you are giving on the command line in the keyring. Hence it is 
prompting for the gnome-keyring password.  If you also specify –no-auth-cache, 
then you might not get a prompt.

-Steve

From: Jeremy Wall [mailto:jw...@google.com]
Sent: Tuesday, July 13, 2010 8:09 AM
To: users@subversion.apache.org
Subject: Possible bug in svn's gnome-keyring support?

Hi,

I noticed after updating svn to version 1.6.6 that svn now has gnome-keyring 
support.

However It seems to ignore the --username --password flags if that support is 
enabled. I don't use the gnome-keyring or even gnome but subversion refused to 
let me commit until I turned off password-stores in the config despite giving 
it a valid username and password. Instead it would prompt for the gnome-keyring 
password which is not set up for me and refuse to continue until I successfully 
authenticated to the keyring.

This seems like the wrong behavior to me. Is it intended?

Here is my subversion information:

svn, version 1.6.6 (r40053)
   compiled Dec 12 2009, 05:06:12

Copyright (C) 2000-2009 CollabNet.
Subversion is open source software, see http://subversion.tigris.org/
This product includes software developed by CollabNet (http://www.Collab.Net/).

The following repository access (RA) modules are available:

* ra_neon : Module for accessing a repository via WebDAV protocol using Neon.
  - handles 'http' scheme
  - handles 'https' scheme
* ra_svn : Module for accessing a repository using the svn network protocol.
  - with Cyrus SASL authentication
  - handles 'svn' scheme
* ra_local : Module for  accessing a repository on local disk.
  - handles 'file' scheme


Jeremy

RE: Possible bug in svn's gnome-keyring support?

2010-07-13 Thread Varnau, Steve (Neoview)

It should only use gnome if it is specified in your config file 
(~/.subversion/config):

password-stores = gnome-keyring

-Steve

From: Jeremy Wall [mailto:jw...@google.com]
Sent: Tuesday, July 13, 2010 9:11 AM
To: Varnau, Steve (Neoview)
Cc: users@subversion.apache.org
Subject: Re: Possible bug in svn's gnome-keyring support?

The strangeness is it's insistence on using the Gnome Keyring despite me not 
using Gnome. Is this the expected default behaviour?
On Tue, Jul 13, 2010 at 11:08 AM, Varnau, Steve (Neoview) 
mailto:steve.var...@hp.com>> wrote:
Jeremy,

If svn is configured to use a Gnome keyring, then it is trying to store the 
password you are giving on the command line in the keyring. Hence it is 
prompting for the gnome-keyring password.  If you also specify –no-auth-cache, 
then you might not get a prompt.

-Steve

From: Jeremy Wall [mailto:jw...@google.com<mailto:jw...@google.com>]
Sent: Tuesday, July 13, 2010 8:09 AM
To: users@subversion.apache.org<mailto:users@subversion.apache.org>
Subject: Possible bug in svn's gnome-keyring support?

Hi,

I noticed after updating svn to version 1.6.6 that svn now has gnome-keyring 
support.

However It seems to ignore the --username --password flags if that support is 
enabled. I don't use the gnome-keyring or even gnome but subversion refused to 
let me commit until I turned off password-stores in the config despite giving 
it a valid username and password. Instead it would prompt for the gnome-keyring 
password which is not set up for me and refuse to continue until I successfully 
authenticated to the keyring.

This seems like the wrong behavior to me. Is it intended?

Here is my subversion information:

svn, version 1.6.6 (r40053)
   compiled Dec 12 2009, 05:06:12

Copyright (C) 2000-2009 CollabNet.
Subversion is open source software, see http://subversion.tigris.org/
This product includes software developed by CollabNet (http://www.Collab.Net/).

The following repository access (RA) modules are available:

* ra_neon : Module for accessing a repository via WebDAV protocol using Neon.
  - handles 'http' scheme
  - handles 'https' scheme
* ra_svn : Module for accessing a repository using the svn network protocol.
  - with Cyrus SASL authentication
  - handles 'svn' scheme
* ra_local : Module for  accessing a repository on local disk.
  - handles 'file' scheme

Jeremy

RE: Possible bug in svn's gnome-keyring support?

2010-07-13 Thread Varnau, Steve (Neoview)

Also, I guess it could be getting options from system-wide config 
(/etc/subversion on linux).

-Steve

-Original Message-
From: Mark Phippard [mailto:markp...@gmail.com] 
Sent: Tuesday, July 13, 2010 9:29 AM
To: Jeremy Wall
Cc: Varnau, Steve (Neoview); users@subversion.apache.org
Subject: Re: Possible bug in svn's gnome-keyring support?

If the option is not set, the default behavior is to use what is
available.  If you have gnome-keyring support it tries to use it.

On Tue, Jul 13, 2010 at 12:22 PM, Jeremy Wall  wrote:
> There was no password-stores line in my config file. I had to add a
> password-stores line to the file to disable it. Is there a second config
> file it might be pulling from that I'm unaware of?
>
> On Tue, Jul 13, 2010 at 11:15 AM, Varnau, Steve (Neoview)
>  wrote:
>>
>> It should only use gnome if it is specified in your config file
>> (~/.subversion/config):
>>
>>
>>
>> password-stores = gnome-keyring
>>
>>
>>
>> -Steve
>>
>>
>>
>> From: Jeremy Wall [mailto:jw...@google.com]
>> Sent: Tuesday, July 13, 2010 9:11 AM
>> To: Varnau, Steve (Neoview)
>> Cc: users@subversion.apache.org
>> Subject: Re: Possible bug in svn's gnome-keyring support?
>>
>>
>>
>> The strangeness is it's insistence on using the Gnome Keyring despite me
>> not using Gnome. Is this the expected default behaviour?
>>
>> On Tue, Jul 13, 2010 at 11:08 AM, Varnau, Steve (Neoview)
>>  wrote:
>>
>> Jeremy,
>>
>>
>>
>> If svn is configured to use a Gnome keyring, then it is trying to store
>> the password you are giving on the command line in the keyring. Hence it is
>> prompting for the gnome-keyring password.  If you also specify
>> -no-auth-cache, then you might not get a prompt.
>>
>>
>>
>> -Steve
>>
>>
>>
>> From: Jeremy Wall [mailto:jw...@google.com]
>> Sent: Tuesday, July 13, 2010 8:09 AM
>> To: users@subversion.apache.org
>> Subject: Possible bug in svn's gnome-keyring support?
>>
>>
>>
>> Hi,
>>
>>
>>
>> I noticed after updating svn to version 1.6.6 that svn now has
>> gnome-keyring support.
>>
>>
>>
>> However It seems to ignore the --username --password flags if that support
>> is enabled. I don't use the gnome-keyring or even gnome but subversion
>> refused to let me commit until I turned off password-stores in the config
>> despite giving it a valid username and password. Instead it would prompt for
>> the gnome-keyring password which is not set up for me and refuse to continue
>> until I successfully authenticated to the keyring.
>>
>>
>>
>> This seems like the wrong behavior to me. Is it intended?
>>
>>
>>
>> Here is my subversion information:
>>
>>
>>
>> svn, version 1.6.6 (r40053)
>>
>>    compiled Dec 12 2009, 05:06:12
>>
>>
>>
>> Copyright (C) 2000-2009 CollabNet.
>>
>> Subversion is open source software, see http://subversion.tigris.org/
>>
>> This product includes software developed by CollabNet
>> (http://www.Collab.Net/).
>>
>>
>>
>> The following repository access (RA) modules are available:
>>
>>
>>
>> * ra_neon : Module for accessing a repository via WebDAV protocol using
>> Neon.
>>
>>   - handles 'http' scheme
>>
>>   - handles 'https' scheme
>>
>> * ra_svn : Module for accessing a repository using the svn network
>> protocol.
>>
>>   - with Cyrus SASL authentication
>>
>>   - handles 'svn' scheme
>>
>> * ra_local : Module for  accessing a repository on local disk.
>>
>>   - handles 'file' scheme
>>
>>
>>
>>
>>
>> Jeremy
>>
>>
>



-- 
Thanks

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

Dangerous to keep re-integrated branches alive?

2011-02-11 Thread Varnau, Steve (Neoview)

Hi all,

My development group uses quite a bit of branching. I'm trying to train folks 
to delete a task branch once it is integrated and create a new one for the next 
task. Of course the svnbook gives the recipe for "Keeping a reintegrated branch 
alive", by using a record-only merge to block the integrated revision from 
being merged back to the task branch later on. (when sync-ing up the branch)

It has always seemed to me that that is risky. If there were changes in the 
re-integration merge for conflict resolution, etc, then those changes are also 
being blocked from being merged back to the (kept-alive) task branch. Future 
changes on the task branch don't include those fixes and future re-integrations 
could potentially even over-write them (since the mergeinfo data says we're all 
up-to-date with respect to that prior revision).

I hope that description is not too abstract. Am I worrying about a non-existent 
problem, or is there really potential to drop a change that should have gotten 
merged forward?

I know we can always go back in history and find the change, but I'd rather set 
up our branch/merge process to be as correct as possible and not rely on 
testing to find that we dropped bit of code.

TIA,
-Steve

RE: Dangerous to keep re-integrated branches alive?

2011-02-14 Thread Varnau, Steve (Neoview)

-Original Message-
From: Stefan Sperling [mailto:s...@elego.de] 
Sent: Saturday, February 12, 2011 5:10 AM
To: Daniel Becroft
Cc: Varnau, Steve (Neoview); users@subversion.apache.org
Subject: Re: Dangerous to keep re-integrated branches alive?

On Sat, Feb 12, 2011 at 04:08:26PM +1000, Daniel Becroft wrote:
> On Sat, Feb 12, 2011 at 1:10 PM, Varnau, Steve (Neoview) <
> steve.var...@hp.com> wrote:
> 
> >  Hi all,
> >
> > My development group uses quite a bit of branching. I’m trying to train
> > folks to delete a task branch once it is integrated and create a new one for
> > the next task. Of course the svnbook gives the recipe for “Keeping a
> > reintegrated branch alive”, by using a record-only merge to block the
> > integrated revision from being merged back to the task branch later on.
> > (when sync-ing up the branch)
> >
> > It has always seemed to me that that is risky. If there were changes in the
> > re-integration merge for conflict resolution, etc, then those changes are
> > also being blocked from being merged back to the (kept-alive) task branch.
> > Future changes on the task branch don’t include those fixes and future
> > re-integrations could potentially even over-write them (since the mergeinfo
> > data says we’re all up-to-date with respect to that prior revision).

I would say that depends on the kind of conflict resolution.

Maybe you're resolving a conflict in a way that is specific to trunk
and must never go to the branch (i.e. you will keep the conflicting
piece of code for a while and resolve it later). In that case, it's
correct that the revision is blocked from being merged into the branch.

Else, you should require that the reintegrate merge is conflict-free.
So if you run into the situation where another commit to trunk sneaks
in after you sync but before you reintegrate, you simply sync again
and then try to reintegrate again.

> 
> My understanding is that this should never happen. During a reintegration
> merge, there is validation that all revisions from the target (normally
> /trunk) have been merged across into the branch - any conflict resolution is
> done during this merge. The reintegration merge then does a basic file
> compare, and merges across.

It can happen if someone commits to trunk after you sync the branch
to trunk but before you reintegrate it.

> After the reintegration merge, /trunk and the branch should be bit-by-bit
> identical. Period.

No. That's not true in the general case. It's a common misunderstanding though.
See here for details: 
http://mail-archives.apache.org/mod_mbox/subversion-users/201009.mbox/%3c20100929200923.gc7...@ted.stsp.name%3E

--
Thanks for both replies.  So, at least one could do a double-check if the files 
involved in the re-integration check-in revision are identical on the branch. 
They should be, and if so, then it is safe to block the merge and keep the 
branch alive.

-Steve

RE: Dangerous to keep re-integrated branches alive?

2011-02-14 Thread Varnau, Steve (Neoview)



> -Original Message-
> From: Stefan Sperling [mailto:s...@elego.de]
> Sent: Monday, February 14, 2011 9:54 AM
> To: Varnau, Steve (Neoview)
> Cc: Daniel Becroft; users@subversion.apache.org
> Subject: Re: Dangerous to keep re-integrated branches alive?
> 
> On Mon, Feb 14, 2011 at 05:41:03PM +, Varnau, Steve (Neoview)
> wrote:
> >
> >
> > -Original Message-
> > From: Stefan Sperling
> > Sent: Saturday, February 12, 2011 5:10 AM
> > To: Daniel Becroft
> > Cc: Varnau, Steve (Neoview); users@subversion.apache.org
> 
> > Subject: Re: Dangerous to keep re-integrated branches alive?
> > > After the reintegration merge, /trunk and the branch should be bit-
> by-bit
> > > identical. Period.
> >
> > No. That's not true in the general case. It's a common
> misunderstanding though.
> > See here for details: http://mail-
> archives.apache.org/mod_mbox/subversion-
> users/201009.mbox/%3c20100929200923.gc7...@ted.stsp.name%3E
> >
> > --
> > Thanks for both replies.  So, at least one could do a double-check if
> the files involved in the re-integration check-in revision are
> identical on the branch. They should be, and if so, then it is safe to
> block the merge and keep the branch alive.
> >
> > -Steve
> 
> No, the files can differ. E.g. consider what happens if the branch modifies
> the very last line of a file. Now the branch is synced to trunk to prepare
> it for reintegration. The file receives no changes.  Next, someone commits
> a change to trunk changing the very first line of the file. Then you
> perform the reintegrate merge, and it's likely that this merge is
> conflict-free (unless the file is very short). Now you commit the result
> of the reintegration merge, and the files on the branch and the trunk are
> not the same -- they differ in the first line.

Okay, but then I would not want to block that revision with a record-only 
merge, right?  I would want to pick up that merge resolution the next time I 
sync-up the branch.

-Steve

RE: Dangerous to keep re-integrated branches alive?

2011-02-14 Thread Varnau, Steve (Neoview)

> -Original Message-
> From: Stefan Sperling [mailto:s...@elego.de]
> Sent: Monday, February 14, 2011 11:27 AM
> To: Varnau, Steve (Neoview)
> Cc: Daniel Becroft; users@subversion.apache.org
> Subject: Re: Dangerous to keep re-integrated branches alive?
> 
> On Mon, Feb 14, 2011 at 06:05:26PM +, Varnau, Steve (Neoview)
> wrote:
> > > -Original Message-
> > > From: Stefan Sperling
> > > No, the files can differ. E.g. consider what happens if the branch
> modifies
> > > the very last line of a file. Now the branch is synced to trunk to
> prepare
> > > it for reintegration. The file receives no changes.  Next, someone
> commits
> > > a change to trunk changing the very first line of the file. Then
> you
> > > perform the reintegrate merge, and it's likely that this merge is
> > > conflict-free (unless the file is very short). Now you commit the
> result
> > > of the reintegration merge, and the files on the branch and the
> trunk are
> > > not the same -- they differ in the first line.
> >
> > Okay, but then I would not want to block that revision with a record-
> only merge, right?  I would want to pick up that merge resolution the
> next time I sync-up the branch.
> >
> 
> Which revision do you intend to block, precisely?
> 
> I think you eventually want to merge into the branch the revision that
> added the first line to the file on trunk.
> But that is not the same revision as the one that committed the result
> of the reintegrate merge. So in this example it's perfectly fine to
> block
> the reintegration revision from being merged into the branch, isn't it?

Ah, quite right.  Then the harder case is if the intervening change to trunk 
also changed the last line. Then my reintegration merge has to do conflict 
resolution. Perhaps some combination of the changes on that last line.  I 
commit that to trunk, and block my latest trunk revision from being merged back 
to my branch.  So, the next time I do synch up the branch, I get to resolve 
that same conflict again on the branch, hopefully the same or better resolution 
as on trunk.

That seems fine. As long as I did not get fancy and make other gratuitous 
changes that were not strictly conflict resolution in the reintegration merge, 
it should be okay to keep the branch alive.

Thanks for helping me think that through.

-Steve

Merge Conflict on Windows with eol-style & mergeinfo properties

2011-02-23 Thread Varnau, Steve (Neoview)

Hi,

I could not find this issue in the issue tracker.  We're trying to keep the 
svn:mergeinfo properties on top-level directories, but I found  a few text 
files in our repository that have the property.  When a merge is done that 
should be just a branch synch-up merge, the files are marked as conflicted, and 
the entire file is one big conflict, as if it is an EOL character problem.

All of the files that are marked as conflicted have in common two properties. 
They have an svn:mergeinfo, and they have svn:eol-style = native.  Both 
branches have the same svn:eol-style value. The text file that did not have an 
svn:eol-style property merged just fine.

When the files are edited (Tortoise "Edit conflicts") it shows no conflicts -- 
merge with no problem. Looking at the files, there are no EOL character 
differences. Both sides (left & right files, and both sides of the working 
conflict file) have CRLF.

The files also merge fine on Linux.
The files also merge fine if given the option to ignore end-of-line.
The problem occurs whether the merge is done via Tortoise or command-line on 
Windows.
Svn version 1.6.15.

Somehow it seems to be giving up merging these files only when there is a 
svn:mergeinfo property.

I will try to just remove the mergeinfo property on all the files, but wondered 
if this is a general bug.

-Steve

RE: Merge Conflict on Windows with eol-style & mergeinfo properties

2011-02-24 Thread Varnau, Steve (Neoview)



> -Original Message-
> From: Johan Corveleyn [mailto:jcor...@gmail.com]
> Sent: Thursday, February 24, 2011 1:47 AM
> To: Varnau, Steve (Neoview)
> Cc: users@subversion.apache.org
> Subject: Re: Merge Conflict on Windows with eol-style & mergeinfo
> properties
> 
> On Thu, Feb 24, 2011 at 12:56 AM, Varnau, Steve (Neoview)
>  wrote:
> > Hi,
> >
> > I could not find this issue in the issue tracker.  We're trying to
> keep the
> > svn:mergeinfo properties on top-level directories, but I found  a few
> text
> > files in our repository that have the property.  When a merge is done
> that
> > should be just a branch synch-up merge, the files are marked as
> conflicted,
> > and the entire file is one big conflict, as if it is an EOL character
> > problem.
> >
> > All of the files that are marked as conflicted have in common two
> > properties. They have an svn:mergeinfo, and they have svn:eol-style =
> > native.  Both branches have the same svn:eol-style value. The text
> file that
> > did not have an svn:eol-style property merged just fine.
> >
> > When the files are edited (Tortoise "Edit conflicts") it shows no
> conflicts
> > -- merge with no problem. Looking at the files, there are no EOL
> character
> > differences. Both sides (left & right files, and both sides of the
> working
> > conflict file) have CRLF.
> >
> > The files also merge fine on Linux.
> > The files also merge fine if given the option to ignore end-of-line.
> > The problem occurs whether the merge is done via Tortoise or command-
> line on
> > Windows.
> > Svn version 1.6.15.
> >
> > Somehow it seems to be giving up merging these files only when there
> is a
> > svn:mergeinfo property.
> >
> > I will try to just remove the mergeinfo property on all the files,
> but
> > wondered if this is a general bug.
> 
> I think this is the following issue:
> 
> http://subversion.tigris.org/issues/show_bug.cgi?id=3657 - dav update
> report handler in skelta mode can cause spurious conflicts
> 
> (this issue previously had another summary: "phantom svn:eol-style
> changes cause spurious merge text conflicts", which may sound more
> recognizable, but this was later changed when they found out more
> about the issue).
> 
> It describes more or less the same situation: a merge with some prop
> change which happens together with a text change, and the entire file
> is marked as conflicted. I've run into this situation myself a couple
> of times (I then just resolved the conflict by choosing "theirs-full"
> or something, after having assured myself that this was indeed the
> issue).
> 
> It's fixed in svn trunk, so scheduled to be in the upcoming 1.7
> release. AFAIK, it's not currently nominated for backport to 1.6.
> 
> Cheers,
> --
> Johan

Yes, that does appear to be the one!  Thank you.

-Steve

Merge tracking bug - inherited merge-range

2011-05-09 Thread Varnau, Steve (Neoview)

Greetings,

I have a merge tracking bug to report.  It seems like there are a lot of steps 
to re-produce it, but we discovered this in the real world, and it took a long 
while to figure out what was going on and to re-produce it.

We are running 1.6.15 clients.  We have lots of branching, and unfortunately 
svn:mergeinfo at multiple levels. This bug apparently only shows up if you 
merge two levels of directory that have new mergeinfo properties.  The lower 
level directory does not get updated correctly and causes duplicate merge 
conflicts later.

Yes, I know "best practice" says to merge only at the top-level, but in a large 
project, those merge-tracking properties can grow like weeds.

The example steps below to reproduce use multiple branches just to produce the 
mergeinfo at multiple directory levels. There might be a simpler way to 
reproduce it.

I did not find anything in the issue tracker, and I have not tried this with 
1.6.16 or with pre-release 1.7.

-Steve

# create sub-directory tree
$ svn co file:///c:/temp/svn-test/trunk trunk-wc
$ cd trunk-wc/
$ svn mkdir subA
$ svn mkdir subA/subB
$ svn ci -m "need 2 directories"
$ svn cp ^/trunk ^/branch/br1

# first branch adds some content
$ cd ..
$ svn co file:///c:/temp/svn-test/branch/br1 br1-wc
$ cd br1-wc/subA
$ touch foo
$ touch subB/bar
$ svn add foo subB/bar
$ svn ci -m "br1 adds"

# second project branch picks up the directories before project 1 delivers
# third and forth start later
$ cd ../..
$ cd trunk-wc/
$ svn cp ^/trunk ^/branch/br2 -m "victim project"
$ svn merge --reintegrate ^/branch/br1
$ svn ci -m ""
$ svn cp ^/trunk ^/branch/br3 -m "foo project"
$ svn cp ^/trunk ^/branch/br4 -m "bar project"

# three projects working concurrently, project 3 & 4 make changes
$ cd ..
$ svn co file:///c:/temp/svn-test/branch/br2 br2-wc
$ svn co file:///c:/temp/svn-test/branch/br3 br3-wc
$ svn co file:///c:/temp/svn-test/branch/br4 br4-wc
$ cd br3-wc/subA/
$ echo "change" > foo
$ svn ci -m ""
$ cd ../../br4-wc/subA/subB/
$ echo "change" > bar
$ svn ci -m ""

# project 2 first synchs up the changes from br1
$ cd ../../../br2-wc/
$ svn merge ^/trunk
$ svn ci -m "synch 1"
$ svn up
At revision 88.

# project 3 & 4 each deliver content AND incidentally add svn:merginfo 
properties to subA & subB
$ cd ../trunk-wc/subA/subB/
$ svn up
$ svn merge --reintegrate ^/branch/br4/subA/subB
$ svn ci -m "deliver bar"
Committed revision 89.
$ cd ..
$ svn up
$ svn merge --reintegrate ^/branch/br3/subA
$ svn ci -m "deliver foo"
Committed revision 90.

# project 2 synchs up again, including svn:mergeinfo
$ cd ../../br2-wc/
$ svn merge ^/trunk
--- Merging r88 through r90 into '.':
UsubA\foo
UsubA\subB\bar
 U   subA\subB
 U   subA
# at this point mergeinfo is correct for subA, but not for subB

# The content looks okay, so we check in and try another synch merge
# Even though nothing changed on trunk, we get duplicate merge conflict
$ svn ci -m "synch 2"
$ svn up
At revision 91.
$ svn merge ^/trunk

--- Merging r82 through r87 into 'subA\subB':
   C subA\subB\bar
Summary of conflicts:
  Tree conflicts: 1

RE: SVN question

2011-05-23 Thread Varnau, Steve (Neoview)

Christopher,

The problem is not with your perl code. Apparently, update returns success if 
you give it a path that does not exist in the current working directory.


Ø  svn update foobar

At revision 3158.

Ø  echo $?

0

For Svn 1.6.15, anyway. Seems to hold for linux & windows.

-Steve

From: Hahn, Christopher (SAN DIEGO)
Sent: Monday, May 23, 2011 11:34 AM
To: users@subversion.apache.org
Subject: SVN question

Hello,

I have been wondering how best to capture errors from
the SVN command line.

I wanted to show you how a basic test is failing.

Consider the simple code snippet:
==
use strict;
my $options=" --username builduser --password ";

chdir("C:\\source");
my $output = `svn update --depth=infinity mang $options`;

die "svn failed with errorcode $?" if $?;
print "We survived!\n";
==

This command works if the "mang" above is changed to "main"
(which does exist at c:\source).

However, both code have this result:
==
C:\source\cm\script>perl svntest.pl
We survived!

C:\source\cm\script>perl svntest.pl
We survived!
==

What am I doing wrong?

Chris



[cid:image001.png@01CAF080.AD65F1E0]

Christopher Hahn
The Dude
Software Production Engineering
R&D Services, Hewlett-Packard
Phone: 858-655-4096
Cell: 619-630-9791
ch...@hp.com

Visit our SPE Portal





<>

RE: SVN question

2011-05-23 Thread Varnau, Steve (Neoview)

svn does not always return success. For instance:

> svn ls
svn: '.' is not a working copy
> echo $?
1

I think this is the more normal mode that I script against.  I'm not sure why 
the update sub-command is so forgiving.

-Steve

From: Hahn, Christopher (SAN DIEGO)
Sent: Monday, May 23, 2011 1:54 PM
To: Varnau, Steve (Neoview); users@subversion.apache.org
Subject: RE: SVN question

Steve,

Thank you for taking the time.

I also saw thisI was wondering what users do to get something similar 
working.

The same thing happens under Perforce.  The command "p4" always returns a
successful exit code.  The way around that is the odd "-s" switch which causes 
the
tool to emit a string like "exit: #" where the underlying commands success or 
failure
was specified.  Is there perhaps some similar technique for SVN?

I checked the svn Global Options and did not see anything similar.

I suppose that I can just use a pipe and watch for strings that I expect.....

Take care,

Christopher

From: Varnau, Steve (Neoview)
Sent: Monday, May 23, 2011 1:33 PM
To: Hahn, Christopher (SAN DIEGO); users@subversion.apache.org
Subject: RE: SVN question

Christopher,

The problem is not with your perl code. Apparently, update returns success if 
you give it a path that does not exist in the current working directory.


Ø  svn update foobar

At revision 3158.

Ø  echo $?

0

For Svn 1.6.15, anyway. Seems to hold for linux & windows.

-Steve

From: Hahn, Christopher (SAN DIEGO)
Sent: Monday, May 23, 2011 11:34 AM
To: users@subversion.apache.org
Subject: SVN question

Hello,

I have been wondering how best to capture errors from
the SVN command line.

I wanted to show you how a basic test is failing.

Consider the simple code snippet:
==
use strict;
my $options=" --username builduser --password ";

chdir("C:\\source");
my $output = `svn update --depth=infinity mang $options`;

die "svn failed with errorcode $?" if $?;
print "We survived!\n";
==

This command works if the "mang" above is changed to "main"
(which does exist at c:\source).

However, both code have this result:
==
C:\source\cm\script>perl svntest.pl
We survived!

C:\source\cm\script>perl svntest.pl
We survived!
==

What am I doing wrong?

Chris



[cid:image001.png@01CAF080.AD65F1E0]

Christopher Hahn
The Dude
Software Production Engineering
R&D Services, Hewlett-Packard
Phone: 858-655-4096
Cell: 619-630-9791
ch...@hp.com<mailto:christopher.h...@hp.com>

Visit our SPE Portal<http://teams5.sharepoint.hp.com/teams/SPE/default.aspx>





<>

RE: SVN question

2011-05-23 Thread Varnau, Steve (Neoview)



> -Original Message-
> From: Daniel Shahaf [mailto:d...@daniel.shahaf.name]
> Sent: Monday, May 23, 2011 2:37 PM
> To: Varnau, Steve (Neoview)
> Cc: Hahn, Christopher (SAN DIEGO); users@subversion.apache.org
> Subject: Re: SVN question
> 
> 'svn up nonexistent' will pull in a file (inappropriately) called
> 'nonexistent' that has been created on the server in a revision newer
> than the BASE revision of the working copy.

Quite true, but update does not complain whether or not it finds such a file. 
That seems a bit surprising.

It also does not give an error if the current directory is not a working copy, 
and it can't figure out where to update from:

> svn update foobar
Skipped 'foobar'

Okay, at least it gives a message, but not returning error, seems... surprising.

-Steve

> 
> Varnau, Steve (Neoview) wrote on Mon, May 23, 2011 at 21:30:26 +:
> > svn does not always return success. For instance:
> >
> > > svn ls
> > svn: '.' is not a working copy
> > > echo $?
> > 1
> >
> > I think this is the more normal mode that I script against.  I'm not
> sure why the update sub-command is so forgiving.
> >
> > -Steve
> >
> > From: Hahn, Christopher (SAN DIEGO)
> > Sent: Monday, May 23, 2011 1:54 PM
> > To: Varnau, Steve (Neoview); users@subversion.apache.org
> > Subject: RE: SVN question
> >
> > Steve,
> >
> > Thank you for taking the time.
> >
> > I also saw thisI was wondering what users do to get something
> similar working.
> >
> > The same thing happens under Perforce.  The command "p4" always
> returns a
> > successful exit code.  The way around that is the odd "-s" switch
> which causes the
> > tool to emit a string like "exit: #" where the underlying commands
> success or failure
> > was specified.  Is there perhaps some similar technique for SVN?
> >
> > I checked the svn Global Options and did not see anything similar.
> >
> > I suppose that I can just use a pipe and watch for strings that I
> expect.
> >
> > Take care,
> >
> > Christopher
> >
> > From: Varnau, Steve (Neoview)
> > Sent: Monday, May 23, 2011 1:33 PM
> > To: Hahn, Christopher (SAN DIEGO); users@subversion.apache.org
> > Subject: RE: SVN question
> >
> > Christopher,
> >
> > The problem is not with your perl code. Apparently, update returns
> success if you give it a path that does not exist in the current working
> directory.
> >
> >
> > Ø  svn update foobar
> >
> > At revision 3158.
> >
> > Ø  echo $?
> >
> > 0
> >
> > For Svn 1.6.15, anyway. Seems to hold for linux & windows.
> >
> > -Steve
> >
> > From: Hahn, Christopher (SAN DIEGO)
> > Sent: Monday, May 23, 2011 11:34 AM
> > To: users@subversion.apache.org
> > Subject: SVN question
> >
> > Hello,
> >
> > I have been wondering how best to capture errors from
> > the SVN command line.
> >
> > I wanted to show you how a basic test is failing.
> >
> > Consider the simple code snippet:
> > ==
> > use strict;
> > my $options=" --username builduser --password ";
> >
> > chdir("C:\\source");
> > my $output = `svn update --depth=infinity mang $options`;
> >
> > die "svn failed with errorcode $?" if $?;
> > print "We survived!\n";
> > ==
> >
> > This command works if the "mang" above is changed to "main"
> > (which does exist at c:\source).
> >
> > However, both code have this result:
> > ==
> > C:\source\cm\script>perl svntest.pl
> > We survived!
> >
> > C:\source\cm\script>perl svntest.pl
> > We survived!
> > ==
> >
> > What am I doing wrong?
> >
> > Chris
> >
> > 
> >
> > [cid:image001.png@01CAF080.AD65F1E0]
> >
> > Christopher Hahn
> > The Dude
> > Software Production Engineering
> > R&D Services, Hewlett-Packard
> > Phone: 858-655-4096
> > Cell: 619-630-9791
> > ch...@hp.com<mailto:christopher.h...@hp.com>
> >
> > Visit our SPE
> Portal<http://teams5.sharepoint.hp.com/teams/SPE/default.aspx>
> >
> > 
> >
> >
> >
>

RE: Possible bug: --stop-on-copy stops too early

2011-05-24 Thread Varnau, Steve (Neoview)

> -Original Message-
> From: Dirk Heinrichs [mailto:dirk.heinri...@capgemini.com]
> Sent: Tuesday, May 24, 2011 3:31 AM
> To: users@subversion.apache.org
> Subject: Re: Possible bug: --stop-on-copy stops too early
> 
> Am Dienstag, 24. Mai 2011, 12:22:44 schrieb Stephen Butler:
> 
> > The "A", along with the "from :", means that /software was
> > copied from /PALISNC in this revision, so 'svn log --stop-on-copy'
> > stops at this revision.
> >
> > I searched for "--stop-on-copy" in the bug tracker, and turned up
> >
> >   http://subversion.tigris.org/issues/show_bug.cgi?id=2518
> >   "Allow --stop-on-copy to traverse a fixed number of copies > 1"
> >
> > Unfortunately no one's picked it up yet.  There's an interesting
> > suggestion in the comments: the log shouldn't stop if the copy-source
> > was deleted in the same revision.  Of course, that assumes that the
> > delete and the copy (the two halves of the renaming) were committed in
> the same revision.
> 
> Hmm, if it stops on _any_ copy, then maybe "svn log --stop-on-copy" is
> the wrong command for finding the base rev of a branch. Is there a
> better alternative?

I find it is better for this use case to log from past forward to find this 
info.
This is my trusty command to find a branch point:

svn log -qv -r0:HEAD -l1 --stop-on-copy  

-Steve


> 
> Bye...
> 
>   Dirk
> --
> Dirk Heinrichs  | Tel:  +49 (0)211 56623 316
> Configuration Manager   | Fax:  +49 (0)211 56623 450
> Capgemini Deutschland   | Mail: dirk.heinri...@capgemini.com
> Wanheimerstraße 68  | Web:  http://www.de.capgemini.com
> D-40468 Düsseldorf  | ICQ#: 110037733
> GPG Public Key C2E467BB | Keyserver: wwwkeys.pgp.net

RE: Subversion 1.6 on Ubuntu Server 11.x

2011-06-10 Thread Varnau, Steve (Neoview)

From: Geoff Hoffman [mailto:ghoff...@cardinalpath.com]
Sent: Friday, June 10, 2011 3:26 PM
To: users@subversion.apache.org
Subject: Subversion 1.6 on Ubuntu Server 11.x

I posted about this on the Ubuntu forums but thus far nobody has replied.

When SSH'd into the box and using svn operations, I'm getting the dastardly 
warning about my password is going to get stored to disk unencrypted.

I read about Subversion 1.6 security 
changes.
I read about Subversion 1.6 on Ubuntu Server over at 
superuser.com.
I read about gnome-keyring over at 
stackoverflow.

I've been doing a lot of reading on it.

I have done the following:

* installed gnome-keyring

*edited my ~/.subversion/config to turn
password-stores = gnome-keyring

edited my ~/.subversion/servers to
store-passwords = yes
store-plaintext-passwords = no

Thing is, I'm not using any GUI so it's still not working. Should I try encfs ?

I read another post about a tool from CollabNet called keyring_tool but I don't 
have it on this system. Where do I get that? I've never run into these issues 
before (new distro, new svn version).

Any additional insight would be very much appreciated.

You also have to run the gnome-keyring-daemon. Most of the docs assume you do 
it from a GUI, but you don't have to. Just set up some shell login script to 
start one (per user) if it is not running, and re-use the same environment 
variable values if it is already running.

This site will give you some hints, but the exercise is left to the reader.
http://live.gnome.org/GnomeKeyring/RunningDaemon

You do need to initialize your keyring, which is what the Collabnet 
keyring_tool is for.

-Steve

RE: Merge tracking bug - inherited merge-range

2011-06-17 Thread Varnau, Steve (Neoview)

Now that I have a 1.7-alpha client, I gave this scenario I posted last month 
another try, and it works fine. Not a problem for 1.7.

-Steve

From: Varnau, Steve (Neoview)
Sent: Monday, May 09, 2011 6:06 PM
To: users@subversion.apache.org
Cc: Brackett, Faye
Subject: Merge tracking bug - inherited merge-range

Greetings,

I have a merge tracking bug to report.  It seems like there are a lot of steps 
to re-produce it, but we discovered this in the real world, and it took a long 
while to figure out what was going on and to re-produce it.

We are running 1.6.15 clients.  We have lots of branching, and unfortunately 
svn:mergeinfo at multiple levels. This bug apparently only shows up if you 
merge two levels of directory that have new mergeinfo properties.  The lower 
level directory does not get updated correctly and causes duplicate merge 
conflicts later.

Yes, I know "best practice" says to merge only at the top-level, but in a large 
project, those merge-tracking properties can grow like weeds.

The example steps below to reproduce use multiple branches just to produce the 
mergeinfo at multiple directory levels. There might be a simpler way to 
reproduce it.

I did not find anything in the issue tracker, and I have not tried this with 
1.6.16 or with pre-release 1.7.

-Steve

# create sub-directory tree
$ svn co file:///c:/temp/svn-test/trunk trunk-wc
$ cd trunk-wc/
$ svn mkdir subA
$ svn mkdir subA/subB
$ svn ci -m "need 2 directories"
$ svn cp ^/trunk ^/branch/br1

# first branch adds some content
$ cd ..
$ svn co 
file:///c:/temp/svn-test/branch/br1 br1-wc
$ cd br1-wc/subA
$ touch foo
$ touch subB/bar
$ svn add foo subB/bar
$ svn ci -m "br1 adds"

# second project branch picks up the directories before project 1 delivers
# third and forth start later
$ cd ../..
$ cd trunk-wc/
$ svn cp ^/trunk ^/branch/br2 -m "victim project"
$ svn merge --reintegrate ^/branch/br1
$ svn ci -m ""
$ svn cp ^/trunk ^/branch/br3 -m "foo project"
$ svn cp ^/trunk ^/branch/br4 -m "bar project"

# three projects working concurrently, project 3 & 4 make changes
$ cd ..
$ svn co 
file:///c:/temp/svn-test/branch/br2 br2-wc
$ svn co 
file:///c:/temp/svn-test/branch/br3 br3-wc
$ svn co 
file:///c:/temp/svn-test/branch/br4 br4-wc
$ cd br3-wc/subA/
$ echo "change" > foo
$ svn ci -m ""
$ cd ../../br4-wc/subA/subB/
$ echo "change" > bar
$ svn ci -m ""

# project 2 first synchs up the changes from br1
$ cd ../../../br2-wc/
$ svn merge ^/trunk
$ svn ci -m "synch 1"
$ svn up
At revision 88.

# project 3 & 4 each deliver content AND incidentally add svn:merginfo 
properties to subA & subB
$ cd ../trunk-wc/subA/subB/
$ svn up
$ svn merge --reintegrate ^/branch/br4/subA/subB
$ svn ci -m "deliver bar"
Committed revision 89.
$ cd ..
$ svn up
$ svn merge --reintegrate ^/branch/br3/subA
$ svn ci -m "deliver foo"
Committed revision 90.

# project 2 synchs up again, including svn:mergeinfo
$ cd ../../br2-wc/
$ svn merge ^/trunk
--- Merging r88 through r90 into '.':
UsubA\foo
UsubA\subB\bar
U   subA\subB
U   subA
# at this point mergeinfo is correct for subA, but not for subB

# The content looks okay, so we check in and try another synch merge
# Even though nothing changed on trunk, we get duplicate merge conflict
$ svn ci -m "synch 2"
$ svn up
At revision 91.
$ svn merge ^/trunk

--- Merging r82 through r87 into 'subA\subB':
   C subA\subB\bar
Summary of conflicts:
  Tree conflicts: 1

RE: Apparently Spurious svn:merginfo

2011-06-28 Thread Varnau, Steve (Neoview)



> -Original Message-
> From: Bob Archer [mailto:bob.arc...@amsi.com]
> Sent: Tuesday, June 28, 2011 2:20 PM
> To: Michael Fletcher; users@subversion.apache.org
> Subject: RE: Apparently Spurious svn:merginfo
> 
> > We are having problems with a large number of svn:mergeinfo
> > properties
> > being modified each time we merge.  These svn:mergeinfo are on
> > unrelated
> > files to the actual change being made.  Though it does seem as if
> > they
> > correlate to prior merges that have happened.  If we commit these
> > property changes they will happen again the next time we merge.
> >
> > At this point when we merge we will see 80 files with svn:mergeinfo
> > changed when we might only be merging one file.  It's becoming
> > difficult
> > to determine what exactly we have changed.
> >
> > I looked in the FAQ and googled and nothing exactly seemed to match
> > what
> > we are seeing.
> >
> > Mostly, we have TortoiseSVN 1.6.8 / Subversion 1.6.11 on the client
> > and
> > svn 1.6.15 on our server.  The repository is old, having had nearly
> > every major version of SVN that ever existed.
> >
> > We merge sometimes from our "trunk" to a branch and sometimes from
> > our
> > branches back to trunk.  We often have multiple releases in flight
> > so a
> > fix will be merged from ^/branches/7.00.39 to ^/branches/7.00.40
> > and
> > then to ^/branches/7.00.41 and then to ^/trunk.  Or the reverse.
> >
> > At some point people were reverting the svn:mergeinfo properties
> > and
> > performing the checkin because they didn't know what they did.
> > Nobody
> > should be doing that any more.
> >
> > Any help would be appreciated.
> 
> This is a pretty common complaint people have, I'm surprised you
> couldn't find any threads about it. If I were writing an svn merging FAQ
> this would probably be question number 1 or 2.
> 
> What is most likely happening is that you have mereinfo on your child
> nodes that is not present in your root node. This usually happens when
> someone does a merge for a specific file or folder rather than doing the
> merge at the project root.
> 
> I was going to write all about this, but quickly was able to find this
> article on line that saves me much typing.
> 
> http://blog.syntevo.net/2011/03/16/130026864.html
> 
> BOb

It looks like the 1.7 merge command will make the problem a bit better in at 
least two ways.
1) It will only update mergeinfo on sub-trees that were affected in the merge, 
even if other sub-trees have mergeinfo properties. (I am probably not doing 
full justice to this change -- see 
http://subversion.apache.org/docs/release-notes/1.7.html#subtree-mergeinfo-recording.)
 
2) As the same link shows, the merge command will be more verbose about when it 
is updating meta-data versus merging content.

Often times, people only merge a sub-tree because they know that the branch 
they worked on only changed content in that one tree. That's fine, but it adds 
more mergeinfo at the sub-tree level, instead of at the branch level.  If you 
want to elide mergeinfo on lower levels, you can run record-only merge(s) at 
the higher level so that the mergeinfo property goes away at lower levels 
without actually removing data (you just move it up to a higher level).  Of 
course you have to do the research to verify it is a safe/correct thing to do 
for that particular circumstance.

I was headed down this path before getting side-tracked on to other work. One 
useful thing to know is which branch meta-data is different from one sub-tree 
to another. I just started comparing merge info on directory path versus 
another via this little script:

#!/bin/bash
dir=$1
if [[ $1 = "." ]]
then
svn pg svn:mergeinfo $1
else
svn pg svn:mergeinfo $1 | sed -e "s,/$1:,:,"
fi

That gives output stripped of relative path info so that they can be directly 
diff'ed to see which merges are missing in which sub-trees.  Caveat: I am not 
sure that's a valid comparison in the future 1.7 world.

-Steve

RE: branch sync with unversioned files results in versioned file being deleted when reintegrated

2011-08-01 Thread Varnau, Steve (Neoview)

From: C L [mailto:cl_...@hotmail.com]
Sent: Sunday, July 31, 2011 8:52 PM
To: users@subversion.apache.org
Subject: branch sync with unversioned files results in versioned file being 
deleted when reintegrated

Hey all,

I found this oddity today with a branch which had an unversioned file in a 
checkout, which I then synced up with a trunk which had a version of the file 
committed.  "svn merge" reported the file skipped and a "svn status" afterwards 
didn't complain about conflicts.  The merge was committed and then reintegrated 
into trunk, which promptly marked the file as being deleted.

Anyone else encounter this?

Yes, this is a common scenario. It is the easiest way to inadvertently lose 
content when merging.
A common problem is that when you do a sync-up merge, which has new files they 
get added in your working copy. You revert the merge, and they get left in the 
working copy as private files (just like reverting any other added file).  You 
then re-try the merge and to avoid over-writing your private files, they get 
skipped.  The skipped messages get lost in the noise of a large merge, but you 
check for conflicts and finding none, you check in.  As far as svn is 
concerned, you intentionally deleted those files in your branch.  
Re-integrating the branch removes them from trunk, (or parent branch).

I tell our developers to always clean up private files after reverting a merge, 
but it is an easy thing to miss.

By my understanding, there are some improvements coming in 1.7 which will 
considerably improve the situation -- better merge reporting and mergeinfo 
recording will not show a skipped file as merged.

-Steve

RE: Possible bug in svn's gnome-keyring support?

RE: Possible bug in svn's gnome-keyring support?

RE: Possible bug in svn's gnome-keyring support?

Dangerous to keep re-integrated branches alive?

RE: Dangerous to keep re-integrated branches alive?

RE: Dangerous to keep re-integrated branches alive?

RE: Dangerous to keep re-integrated branches alive?

Merge Conflict on Windows with eol-style & mergeinfo properties

RE: Merge Conflict on Windows with eol-style & mergeinfo properties

Merge tracking bug - inherited merge-range

RE: SVN question

RE: SVN question

RE: SVN question

RE: Possible bug: --stop-on-copy stops too early

RE: Subversion 1.6 on Ubuntu Server 11.x

RE: Merge tracking bug - inherited merge-range

RE: Apparently Spurious svn:merginfo

RE: branch sync with unversioned files results in versioned file being deleted when reintegrated

18 matches

Site Navigation

Mail list logo

Footer information