AW: Merging a Revision back to the trunk

[Georg Heisenberger]

> > Hi everybody!
> >
> > I’ve got a question about merging a revision of an
> > feature- branch back to the trunk.
> > Sounds quiet simple:
> > - Select the branch
> > - The revision
> >
> > ⇒ The changes made in the specific revision should be
> > applied on my working copy (trunk)
>
> That's not really the use case of a feature branch. But it should work.
>
Maybe, but in this case the feature will die...
Only the changes in one revision I want to move back to the main trunk.
In fact I can do it manually too, but I want to know what's happening here.

> >
> > The “problem” (at least I don’t understand why it’s happening)
> > is that subversion is merging more than one revision.
>
> Well, did you specify the single revision? Also, you will probably want
> to do a --record-only merge from trunk to branch of the merge's commit
> rev if you will want to later --reintegrate the feature branch to
> trunk.

>
> > In my case I only want revision 278.
> > The response of subversion is, that it starts with revision 226
> >
> >
> > The result: I’ve got more things merged to my WC than I wanted to
> >
> > I would be glad, if some can tell me, why that is happening
>
> I'm pretty sure cause you are not specifying a rev number with -r or -
> c.
>

I don't think so.
First I tried it with TortoiseSVN -> there I selected the revision

Afterwards I tried it also with the commandline client and
a parameter like -r 277:278 should do the trick, isn't it?

It tried also the option ignore-ancestry (commandline and tortoise),
but in both cases subversion starts with earlier versions.


> BOb

RE: Tigris binary packages for Windows

[Cooke, Mark]

>> On 2010-04-22 17:06, Cooke, Mark wrote:
>>
>> I am resurrecting this thread to ask if anyone has come 
>> forward to volunteer time and/or effort to resurrect the 
>> windoze binaries as we are still on 1.6.6 against 1.6.11 
>> announced a few days ago.
>>
> From: David Darj [mailto:z...@alagazam.net] 
> Sent: 22 April 2010 21:21
> 
> I have built both 1.6.9 and 1.6.11
> They are available on my webpage http://alagazam.net
> You (and anyone else) is welcome to download and use it.
> 
> The reason I've not announced the release in this (users) 
> list is that I've hoped some people reading the dev list
> (where I did announce it) to download and test it first so
> I know my build environment is okey.
> As the web page says all test on subversion itself is running 
> ok., but the bindings has not been tested.
> 
You star!  Thanks very much.  I will do some testing with apache 2.2 on
windoze using mod_dav_svn and python bindings (to Trac using mod_wsgi)
and report back...


Out of interest, did you use VC6 or VC2008 to compile (there were
suggestions earlier in the thread that there might be some potential
issues using VC2008 binaries against the official apache build which I
am required to use here):

> From: Mark Phippard [mailto:markp...@gmail.com] 
> Sent: 03 March 2010 14:27
> One other "pain" I thought of is that ideally the binaries
> should be built using MSVC 6.0 (I am assuming DJ has not
> changed that).  Since the httpd binaries are built using that
> you can have problems if a newer Visual Studio is used for
> mod_dav_svn.  You also have to deal with distributing the MS
> runtime libraries if a newer version is used.

Also, did you hook up with Troy about the installers ~ I assume that he
would be able to put them on tigris at least until we get a new home on
apache:

> From: Troy Simpson [mailto:t...@ebswift.com] 
> Sent: 02 March 2010 02:45
> 
> I can still build the installer, but I have never built 
> binaries.  The installer code in the repository is NOT the 
> latest code.  I had lost commit access for a time during the 
> transition and by the time I got that access back there are 
> no more binaries, so it has been pointless to continue 
> development.  If someone could produce binaries I could get 
> the installer back on track, otherwise it's not worth 
> spending any time on if the project will not support (as in 
> supply) windows binaries.

~ mark c

Re: Tigris binary packages for Windows

[Olivier Sannier]

David Darj wrote:

On 2010-04-22 17:06, Cooke, Mark wrote:

Folks,

I am resurrecting this thread to ask if anyone has come forward to 
volunteer time and/or effort to resurrect the windoze binaries as we 
are still on 1.6.6 against 1.6.11 announced a few days ago.


In hope...

~ Mark C



I have built both 1.6.9 and 1.6.11
They are available on my webpage http://alagazam.net
You (and anyone else) is welcome to download and use it.
That's awesome. Many thanks for all this, it's a relief to see those 
packages available again.


The reason I've not announced the release in this (users) list is that 
I've hoped some people reading the dev list (where I did announce it) 
to download and test it first so I know my build environment is okey.
Ah, yes, I don't read the dev list, too many messages that I don't have 
a clue what they are talking about.


As the web page says all test on subversion itself is running ok., but 
the bindings has not been tested.
I don't use the bindings, but I just used the rest of it. It works just 
fine, couldn't see a problem with the package. It even installs on top 
of the previous ones, no need to uninstall before installing that one.


Once again, many thanks for this.
As far as I'm concerned, these packages are good to go and should be put 
forward on the SVN website pages.


Regards
Olivier

svn export on long paths failed

[Schroeder, Hartmut]

hi all,
an 'svn export' under Windows results on a long path in:

svn: Can't open
'current\externaltools\build\sources\mavenplugins\pde-maven-plugin\tutor
ials\PDE_Plugin_Tutorial\plugins\test.pde_maven_plugin.simple_applicatio
n\src\main\java\test\pde_maven_plugin\simple_application\ApplicationWork
benchWindowAdvisor.java.tmp': Das System kann den angegebenen Pfad nicht
finden.

with tortoise it's ok.

we have to run that as windows batchfile.
any idas?


Thanks
Hartmut

RE: svn export on long paths failed

[Bert Huijben]

> -Original Message-
> From: Schroeder, Hartmut [mailto:hartmut.schroe...@plath.de]
> Sent: vrijdag 23 april 2010 13:43
> To: users@subversion.apache.org
> Subject: svn export on long paths failed
> 
> hi all,
> an 'svn export' under Windows results on a long path in:
> 
> svn: Can't open
> 'current\externaltools\build\sources\mavenplugins\pde-maven-
> plugin\tutor
> ials\PDE_Plugin_Tutorial\plugins\test.pde_maven_plugin.simple_applicatio
> n\src\main\java\test\pde_maven_plugin\simple_application\ApplicationWo
> rk
> benchWindowAdvisor.java.tmp': Das System kann den angegebenen Pfad
> nicht
> finden.
> 
> with tortoise it's ok.
> 
> we have to run that as windows batchfile.
> any idas?

Windows doesn't support long relative paths. If paths get longer than a
certain limit (MAX_PATH minus a few characters) you have to use absolute
paths.

TortoiseSVN as a Windows Explorer extension always uses absolute paths.

Bert

Re: svn export on long paths failed

[Volker Kopetzky]

Hartmut,

Another reason I received this is that there were duplicate files in the 
subversion directory which are share the same name and extension but in 
different letter case (e.g. CHANGES versus changes). Windows FS is case 
insensitive by default.

Regarding the problem of using long pathnames, you might want to use the subst 
cli tool to reduce the length of the path string. This and some other ideas are 
described in 
http://superuser.com/questions/37737/extend-maximum-file-path-size-in-windows-7.


Beste Grüße,
kind regards,
Volker Kopetzky
vzk Beratung
Germany & Thailand

Am 23.04.2010 um 18:42 schrieb Schroeder, Hartmut:

hi all,
an 'svn export' under Windows results on a long path in:

svn: Can't open
'current\externaltools\build\sources\mavenplugins\pde-maven-plugin\tutor
ials\PDE_Plugin_Tutorial\plugins\test.pde_maven_plugin.simple_applicatio
n\src\main\java\test\pde_maven_plugin\simple_application\ApplicationWork
benchWindowAdvisor.java.tmp': Das System kann den angegebenen Pfad nicht
finden.

with tortoise it's ok.

we have to run that as windows batchfile.
any idas?


Thanks
Hartmut

Question about JavaHL - DiffSummary

[m g]

Hello,

what is the difference between DiffSummary.getPath() and 
DiffSummary.getSource() ?
I've inspected and both seem to return the same String object.
In which cases do they return different things?

Thanks
Mário

Working copy wrong after "svn up"

[Matthias Hryniszak]

Hi there,

here's what I've noticed:

C:\svn>svnadmin create test
C:\svn>svn co file:///C:/svn/test test-wc
C:\svn>cd test-wc
C:\svn\test-wc>svn mkdir folder
C:\svn\test-wc>svn ci -m "Created folder"
C:\svn\test-wc>svn up

Up until this point everything is normal. But if I manually remove the
folder now like this

C:\svn\test-wc>rd /S folder

and then create one with the same name

C:\svn\test-wc>md folder

and then do an update

C:\svn\test-wc>svn up

the folder is shown as deleted even though subversion has not been notified
about this fact (as in svn rm has not been issued anywhere).

Furthermore reverting the working copy does not work and updates skip the
"folder" resource completely.

I perfectly understand that right at the point where I've deleted the folder
by hand and created one with the same name I've committed a crime but either
way the client should be immune to such situation. After all I'm not
modifying the content of .svn folder by hand but the client does in a
destructive manner.


Best regards,
Matthias.

Re: Working copy wrong after "svn up"

[Les Mikesell]

On 4/23/2010 10:10 AM, Matthias Hryniszak wrote:

Hi there,

here's what I've noticed:

C:\svn>svnadmin create test
C:\svn>svn co file:///C:/svn/test test-wc
C:\svn>cd test-wc
C:\svn\test-wc>svn mkdir folder
C:\svn\test-wc>svn ci -m "Created folder"
C:\svn\test-wc>svn up

Up until this point everything is normal. But if I manually remove the
folder now like this

C:\svn\test-wc>rd /S folder

and then create one with the same name

C:\svn\test-wc>md folder

and then do an update

C:\svn\test-wc>svn up

the folder is shown as deleted even though subversion has not been
notified about this fact (as in svn rm has not been issued anywhere).


You've deleted the .svn metadata under that directory.


Furthermore reverting the working copy does not work and updates skip
the "folder" resource completely.


You've deleted the pristine copy under .svn for that directory.  There's 
no copy left to revert.



I perfectly understand that right at the point where I've deleted the
folder by hand and created one with the same name I've committed a crime
but either way the client should be immune to such situation. After all
I'm not modifying the content of .svn folder by hand but the client does
in a destructive manner.


You did remove the .svn data under that directory by hand along with the 
directory itself. If it hurts, don't do that...


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

RE: Working copy wrong after "svn up"

[Bob Archer]

> C:\svn>svnadmin create test
> C:\svn>svn co file:///C:/svn/test test-wc
> C:\svn>cd test-wc
> C:\svn\test-wc>svn mkdir folder
> C:\svn\test-wc>svn ci -m "Created folder"
> C:\svn\test-wc>svn up
> 
> Up until this point everything is normal. But if I manually remove the
> folder now like this
> 
> C:\svn\test-wc>rd /S folder
> 
> and then create one with the same name
> 
> C:\svn\test-wc>md folder
> 
> and then do an update
> 
> C:\svn\test-wc>svn up
> 
> the folder is shown as deleted even though subversion has not been
> notified about this fact (as in svn rm has not been issued anywhere).
> 
> Furthermore reverting the working copy does not work and updates skip the
> "folder" resource completely.
> 
> I perfectly understand that right at the point where I've deleted the
> folder by hand and created one with the same name I've committed a crime
> but either way the client should be immune to such situation. After all
> I'm not modifying the content of .svn folder by hand but the client does
> in a destructive manner.

That does seem a bit strange. However, keep in mind you didn't just delete 
folder you also deleted folder/.svn so and svn st shows the folder as 
unversioned. Even if I co the folder is show the status as ?.

I am assuming that svn is tracking more than the folder name... so that when 
you remove it and recreate it some id or aspect of it is modified. It is also 
strange that if you delete the folder that you created and do an SVN up it 
doesn't come back...

I do think there is a bug here somewhere.

Like you said, "DON'T DO THIS".

BOb

RE: Working copy wrong after "svn up"

[Bob Archer]

> On 4/23/2010 10:10 AM, Matthias Hryniszak wrote:
> > Hi there,
> >
> > here's what I've noticed:
> >
> > C:\svn>svnadmin create test
> > C:\svn>svn co file:///C:/svn/test test-wc
> > C:\svn>cd test-wc
> > C:\svn\test-wc>svn mkdir folder
> > C:\svn\test-wc>svn ci -m "Created folder"
> > C:\svn\test-wc>svn up
> >
> > Up until this point everything is normal. But if I manually remove the
> > folder now like this
> >
> > C:\svn\test-wc>rd /S folder
> >
> > and then create one with the same name
> >
> > C:\svn\test-wc>md folder
> >
> > and then do an update
> >
> > C:\svn\test-wc>svn up
> >
> > the folder is shown as deleted even though subversion has not been
> > notified about this fact (as in svn rm has not been issued anywhere).
> 
> You've deleted the .svn metadata under that directory.
> 
> > Furthermore reverting the working copy does not work and updates skip
> > the "folder" resource completely.
> 
> You've deleted the pristine copy under .svn for that directory.  There's
> no copy left to revert.

Update is totally different than revert. If you delete the folder then do an UP 
the folder is replaced "A". However, if you create a dir then remove that and 
do an UP the folder isn't fetched. It does seem strange. I assume something is 
going on where .svn at the root indicates that folder is there.

BOb






> 
> > I perfectly understand that right at the point where I've deleted the
> > folder by hand and created one with the same name I've committed a crime
> > but either way the client should be immune to such situation. After all
> > I'm not modifying the content of .svn folder by hand but the client does
> > in a destructive manner.
> 
> You did remove the .svn data under that directory by hand along with the
> directory itself. If it hurts, don't do that...
> 
> --
>Les Mikesell
>  lesmikes...@gmail.com

Re: Working copy wrong after "svn up"

[Les Mikesell]

On 4/23/2010 10:49 AM, Bob Archer wrote:



Furthermore reverting the working copy does not work and updates skip
the "folder" resource completely.


You've deleted the pristine copy under .svn for that directory.  There's
no copy left to revert.


Update is totally different than revert. If you delete the folder then do an UP the 
folder is replaced "A". However, if you create a dir then remove that and do an 
UP the folder isn't fetched. It does seem strange. I assume something is going on where 
.svn at the root indicates that folder is there.



It seems wrong to remove an unmanaged item, although in the special case 
of an empty directory I guess it wouldn't make much difference.


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

RE: Working copy wrong after "svn up"

[Bob Archer]

> On 4/23/2010 10:49 AM, Bob Archer wrote:
> >>
> >>> Furthermore reverting the working copy does not work and updates skip
> >>> the "folder" resource completely.
> >>
> >> You've deleted the pristine copy under .svn for that directory.
> There's
> >> no copy left to revert.
> >
> > Update is totally different than revert. If you delete the folder then
> do an UP the folder is replaced "A". However, if you create a dir then
> remove that and do an UP the folder isn't fetched. It does seem strange. I
> assume something is going on where .svn at the root indicates that folder
> is there.
> >
> 
> It seems wrong to remove an unmanaged item, although in the special case
> of an empty directory I guess it wouldn't make much difference.
> 
> --
>Les Mikesell
> lesmikes...@gmail.com

I agree it is wrong. But, I also think something is smarmy here. For example, 
if you create the folder after deleting it with the OS command (rather than 
SVN) then realize your mistake, rd the folder and do svn up it really should 
get the folder from the repo assuming your depth is set to infinity. 

If I do the same thing with a file... delete it (OS cmd), then create the same 
name, svn will report it with a status of "M" and a commit will merge the diff 
between that file and base.

BOb
 

Renaming the source path of a branch and merging

[Bob Archer]

Hi All,

I know I could try this in a test repo... but things always seem to work with 1 
file and 1 line change much better.

The scenerio is this. We have decided to change our repo structure under a 
project a bit. Rather than current dev being in trunk we want to name the 
folder for the next Major.Minor release. So, we will have a branch for planned 
release strategy rather than next release ver always being in branch and branch 
for release. For several reasons.

Anyway... We currently have ProjectName/trunk which is version 6.5.1. Our next 
release will be a major one so a copy of trunk was made to ProjectName/v7.0.0. 
Now, to align the repo with the new strategy we want to rename trunk to v6.5.1. 

Question, if I do this, will I have a problem merging from v6.5.1 to v7.0.0 as 
fixes are applied to v6.5.1 path?

Will there be a problem if I merge while it is still named /trunk and then 
rename it... seeing as the mergeinfo is going to specify /trunk:- or is 
svn smart enough to follow the history back and know that if I do my next merge 
from /v7.0.0 that since trunk was it's ancestor that it won't try to merge in 
the same revisions from the /v7.0.0 path that it already merged in from the 
/trunk path?

Thanks,
BOb

RE: Working copy wrong after "svn up"

[Bob Archer]

> > On 4/23/2010 10:49 AM, Bob Archer wrote:
> > >>
> > >>> Furthermore reverting the working copy does not work and updates
> skip
> > >>> the "folder" resource completely.
> > >>
> > >> You've deleted the pristine copy under .svn for that directory.
> > There's
> > >> no copy left to revert.
> > >
> > > Update is totally different than revert. If you delete the folder then
> > do an UP the folder is replaced "A". However, if you create a dir then
> > remove that and do an UP the folder isn't fetched. It does seem strange.
> I
> > assume something is going on where .svn at the root indicates that
> folder
> > is there.
> > >
> >
> > It seems wrong to remove an unmanaged item, although in the special case
> > of an empty directory I guess it wouldn't make much difference.
> >
> > --
> >Les Mikesell
> > lesmikes...@gmail.com
> 
> I agree it is wrong. But, I also think something is smarmy here. For
> example, if you create the folder after deleting it with the OS command
> (rather than SVN) then realize your mistake, rd the folder and do svn up
> it really should get the folder from the repo assuming your depth is set
> to infinity.
> 
> If I do the same thing with a file... delete it (OS cmd), then create the
> same name, svn will report it with a status of "M" and a commit will merge
> the diff between that file and base.
> 

Also, consider that the metadata for fodler is in /test/.svn not 
/test/folder/.svn

BOb

Re: Working copy wrong after "svn up"

[Les Mikesell]

On 4/23/2010 11:00 AM, Bob Archer wrote:

On 4/23/2010 10:49 AM, Bob Archer wrote:



Furthermore reverting the working copy does not work and updates skip
the "folder" resource completely.


You've deleted the pristine copy under .svn for that directory.

There's

no copy left to revert.


Update is totally different than revert. If you delete the folder then

do an UP the folder is replaced "A". However, if you create a dir then
remove that and do an UP the folder isn't fetched. It does seem strange. I
assume something is going on where .svn at the root indicates that folder
is there.




It seems wrong to remove an unmanaged item, although in the special case
of an empty directory I guess it wouldn't make much difference.




I agree it is wrong. But, I also think something is smarmy here. For example, 
if you create the folder after deleting it with the OS command (rather than 
SVN) then realize your mistake, rd the folder and do svn up it really should 
get the folder from the repo assuming your depth is set to infinity.

If I do the same thing with a file... delete it (OS cmd), then create the same name, svn 
will report it with a status of "M" and a commit will merge the diff between 
that file and base.


That's not equivalent.  Removing/replacing a file is just a local edit 
of a managed item, and the same thing an editor program might do.  The 
equivalent would be removing the containing directory and thus the .svn 
metadata, then putting back the directory and a new file of the same name.


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

JavaHL - when using peg makes the difference in diffSummarize()

[m g]

Hi,

can you provide me at least one case in which passing
a non-null peg revision to SVNClientInterface.diffSummarize()
returns a different result than when passing null ?

Thanks
Mário

Re: Tigris binary packages for Windows

[David Darj]

On 2010-04-23 10:29, Cooke, Mark wrote:

On 2010-04-22 17:06, Cooke, Mark wrote:

I am resurrecting this thread to ask if anyone has come
forward to volunteer time and/or effort to resurrect the
windoze binaries as we are still on 1.6.6 against 1.6.11
announced a few days ago.

   

From: David Darj [mailto:z...@alagazam.net]
Sent: 22 April 2010 21:21

I have built both 1.6.9 and 1.6.11
They are available on my webpage http://alagazam.net
You (and anyone else) is welcome to download and use it.

The reason I've not announced the release in this (users)
list is that I've hoped some people reading the dev list
(where I did announce it) to download and test it first so
I know my build environment is okey.
As the web page says all test on subversion itself is running
ok., but the bindings has not been tested.

 

You star!  Thanks very much.  I will do some testing with apache 2.2 on
windoze using mod_dav_svn and python bindings (to Trac using mod_wsgi)
and report back...

   

Thanx that would be gr8.

Out of interest, did you use VC6 or VC2008 to compile (there were
suggestions earlier in the thread that there might be some potential
issues using VC2008 binaries against the official apache build which I
am required to use here):

   

It's built using the good old VC6 like  D.J Heap previously did.
That way no runtime-dll:s (msvcr*) needs to be distributed with it.


From: Mark Phippard [mailto:markp...@gmail.com]
Sent: 03 March 2010 14:27
One other "pain" I thought of is that ideally the binaries
should be built using MSVC 6.0 (I am assuming DJ has not
changed that).  Since the httpd binaries are built using that
you can have problems if a newer Visual Studio is used for
mod_dav_svn.  You also have to deal with distributing the MS
runtime libraries if a newer version is used.
 

Also, did you hook up with Troy about the installers ~ I assume that he
would be able to put them on tigris at least until we get a new home on
apache:

   

I havn't had any contact with troy, but this mail is cc:d to him as well.
So if he is reading it it would be great if he (or anyone else) want to 
put the there.



From: Troy Simpson [mailto:t...@ebswift.com]
Sent: 02 March 2010 02:45

I can still build the installer, but I have never built
binaries.  The installer code in the repository is NOT the
latest code.  I had lost commit access for a time during the
transition and by the time I got that access back there are
no more binaries, so it has been pointless to continue
development.  If someone could produce binaries I could get
the installer back on track, otherwise it's not worth
spending any time on if the project will not support (as in
supply) windows binaries.
 

~ mark c
   


/David

RE: JavaHL - when using peg makes the difference in diffSummarize()

[Jon Foster]

Hi,

"m g" wrote:
> Subject: JavaHL - when using peg makes the difference in diffSummarize()
>
> can you provide me at least one case in which passing
> a non-null peg revision to SVNClientInterface.diffSummarize()
> returns a different result than when passing null ?
>
> Thanks
> Mário

Have you read the SVN book?  http://svnbook.red-bean.com/
It has a good explanation of peg revisions.

Kind regards,

Jon
--
Please direct all replies to the mailing list.



**
This email and its attachments may be confidential and are intended solely for 
the use of the individual to whom it is addressed. Any views or opinions 
expressed are solely those of the author and do not necessarily represent those 
of Cabot Communications Ltd.

If you are not the intended recipient of this email and its attachments, you 
must take no action based upon them, nor must you copy or show them to anyone.

Cabot Communications Limited
Verona House, Filwood Road, Bristol BS16 3RY, UK
+44 (0) 1179584232

Co. Registered in England number 02817269

Please contact the sender if you believe you have received this email in error.

**


__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
__

Re: JavaHL - when using peg makes the difference in diffSummarize()

[m g]

Hi,

yes I've read it and the examples there in the "Peg and Operative Revisions" 
section make sense.
Yet, I do not know any answer to my question bellow. 
Can you provide me just one example in which passing and not passing a peg 
revision to diffSummarize()
returns a different response? Maybe this is easy for you as I'm new to JavaHL

Thanks
Mário



- Original Message 
From: Jon Foster 
To: m g 
Cc: SubversionUsers 
Sent: Fri, April 23, 2010 6:16:49 PM
Subject: RE: JavaHL - when using peg makes the difference in diffSummarize()

Hi,

"m g" wrote:
> Subject: JavaHL - when using peg makes the difference in diffSummarize()
>
> can you provide me at least one case in which passing
> a non-null peg revision to SVNClientInterface.diffSummarize()
> returns a different result than when passing null ?
>
> Thanks
> Mário

Have you read the SVN book?  http://svnbook.red-bean.com/
It has a good explanation of peg revisions.

Kind regards,

Jon
--
Please direct all replies to the mailing list.



**
This email and its attachments may be confidential and are intended solely for 
the use of the individual to whom it is addressed. Any views or opinions 
expressed are solely those of the author and do not necessarily represent those 
of Cabot Communications Ltd.

If you are not the intended recipient of this email and its attachments, you 
must take no action based upon them, nor must you copy or show them to anyone.

Cabot Communications Limited
Verona House, Filwood Road, Bristol BS16 3RY, UK
+44 (0) 1179584232

Co. Registered in England number 02817269

Please contact the sender if you believe you have received this email in error.

**


__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
__

Re: Working copy wrong after "svn up"

[Matthias Hryniszak]

I'd like to file this as a bug. Could you point me to where I can do it?

Best regards,
Matthias.

2010/4/23 Bob Archer 

> > C:\svn>svnadmin create test
> > C:\svn>svn co file:///C:/svn/test test-wc
> > C:\svn>cd test-wc
> > C:\svn\test-wc>svn mkdir folder
> > C:\svn\test-wc>svn ci -m "Created folder"
> > C:\svn\test-wc>svn up
> >
> > Up until this point everything is normal. But if I manually remove the
> > folder now like this
> >
> > C:\svn\test-wc>rd /S folder
> >
> > and then create one with the same name
> >
> > C:\svn\test-wc>md folder
> >
> > and then do an update
> >
> > C:\svn\test-wc>svn up
> >
> > the folder is shown as deleted even though subversion has not been
> > notified about this fact (as in svn rm has not been issued anywhere).
> >
> > Furthermore reverting the working copy does not work and updates skip the
> > "folder" resource completely.
> >
> > I perfectly understand that right at the point where I've deleted the
> > folder by hand and created one with the same name I've committed a crime
> > but either way the client should be immune to such situation. After all
> > I'm not modifying the content of .svn folder by hand but the client does
> > in a destructive manner.
>
> That does seem a bit strange. However, keep in mind you didn't just delete
> folder you also deleted folder/.svn so and svn st shows the folder as
> unversioned. Even if I co the folder is show the status as ?.
>
> I am assuming that svn is tracking more than the folder name... so that
> when you remove it and recreate it some id or aspect of it is modified. It
> is also strange that if you delete the folder that you created and do an SVN
> up it doesn't come back...
>
> I do think there is a bug here somewhere.
>
> Like you said, "DON'T DO THIS".
>
> BOb
>
>

RE: Working copy wrong after "svn up"

[Bob Archer]

> > C:\svn>svnadmin create test
> > C:\svn>svn co file:///C:/svn/test test-wc
> > C:\svn>cd test-wc
> > C:\svn\test-wc>svn mkdir folder
> > C:\svn\test-wc>svn ci -m "Created folder"
> > C:\svn\test-wc>svn up
> >
> > Up until this point everything is normal. But if I manually remove the
> > folder now like this
> >
> > C:\svn\test-wc>rd /S folder
> >
> > and then create one with the same name
> >
> > C:\svn\test-wc>md folder
> >
> > and then do an update
> >
> > C:\svn\test-wc>svn up
> >
> > the folder is shown as deleted even though subversion has not been
> > notified about this fact (as in svn rm has not been issued anywhere).
> >
> > Furthermore reverting the working copy does not work and updates skip
> the
> > "folder" resource completely.
> >
> > I perfectly understand that right at the point where I've deleted the
> > folder by hand and created one with the same name I've committed a crime
> > but either way the client should be immune to such situation. After all
> > I'm not modifying the content of .svn folder by hand but the client does
> > in a destructive manner.
> I'd like to file this as a bug. Could you point me to where I can do it?

http://subversion.apache.org/issue-tracker.html

BOb

Re: Working copy wrong after "svn up"

[Stefan Sperling]

On Fri, Apr 23, 2010 at 08:19:18PM +0200, Matthias Hryniszak wrote:
> I'd like to file this as a bug. Could you point me to where I can do it?

You won't get much of an answer for filing this as a bug other
than "wait for 1.7".

Subversion's working copy management library is currently undergoing
a rewrite from the bottom up to avoid these kinds of problems.
In 1.7, there will only be a single .svn directory at the root of
the working copy, so these kinds of issues will be easier to deal with.

Stefan

Re: Working copy wrong after "svn up"

[Matthias Hryniszak]

Thanks for the response - that's really great to hear and I guess I'll skip
this one in that case.

Best regards,
Matthias.

2010/4/23 Stefan Sperling 

> On Fri, Apr 23, 2010 at 08:19:18PM +0200, Matthias Hryniszak wrote:
> > I'd like to file this as a bug. Could you point me to where I can do it?
>
> You won't get much of an answer for filing this as a bug other
> than "wait for 1.7".
>
> Subversion's working copy management library is currently undergoing
> a rewrite from the bottom up to avoid these kinds of problems.
> In 1.7, there will only be a single .svn directory at the root of
> the working copy, so these kinds of issues will be easier to deal with.
>
> Stefan
>

Re: Working copy wrong after "svn up"

[Stefan Sperling]

On Fri, Apr 23, 2010 at 08:38:01PM +0200, Matthias Hryniszak wrote:
> Thanks for the response - that's really great to hear and I guess I'll skip
> this one in that case.

On second thought, you can still file an issue, with the intention
that this particular use case will be tested and verified to work
before 1.7 release.

To facilitate this, can you provide a reproduction script (UNIX shell
or Windows cmd, whichever you prefer) which starts by creating an
empty repository and runs svn and other commands until the problem
is triggered? That would help greatly.
We could use this script to reproduce the problem with 1.6,
and later verify that the problem is gone in 1.7.
We could even add a regression test to our test suite based on
your script. (A script is great for this because it is a lot
easier to convert into a regression test than English prose.)

Thanks,
Stefan

version 3 vs 5

[Walid Majid]

Hi,

I am trying to checkout a repository from one Linux machine (A) to another one 
(B) and in the process I am getting the following error message from B:

svn: Expected version '3' of repository; found version '5'

Here is the command that was executed:

svn checkout svn+ssh://u...@a/proj1/svnroot proj1

The default svn versions on the two machines are:
A: 1.1.4
B: 1.6.5

It turns out that version 1.5.2 of svn is also installed on machine A, but is 
somehow not being picked up - I think - while running svn with ssh.  Any 
suggestions?

Thanks in advance.

Majid


  

RE: version 3 vs 5

[Bob Archer]

> I am trying to checkout a repository from one Linux machine (A) to another
> one (B) and in the process I am getting the following error message from
> B:
> 
> svn: Expected version '3' of repository; found version '5'
> 
> Here is the command that was executed:
> 
> svn checkout svn+ssh://u...@a/proj1/svnroot proj1
> 
> The default svn versions on the two machines are:
> A: 1.1.4
> B: 1.6.5
> 
> It turns out that version 1.5.2 of svn is also installed on machine A, but
> is somehow not being picked up - I think - while running svn with ssh.
> Any suggestions?
> 
> Thanks in advance.
> 
> Majid

I don't use that protocol... but I am pretty sure that your SSH session has a 
path to the older version of subversion where the repository was created with a 
newer version. You've got to make sure your SSH session has a path to 1.5.2 
rather than 1.1.4.

BOb

Re: version 3 vs 5

[Ryan Schmidt]

On Apr 23, 2010, at 16:33, Walid Majid wrote:

> I am trying to checkout a repository from one Linux machine (A) to another 
> one (B) and in the process I am getting the following error message from B:
> 
> svn: Expected version '3' of repository; found version '5'
> 
> Here is the command that was executed:
> 
> svn checkout svn+ssh://u...@a/proj1/svnroot proj1
> 
> The default svn versions on the two machines are:
> A: 1.1.4
> B: 1.6.5
> 
> It turns out that version 1.5.2 of svn is also installed on machine A, but is 
> somehow not being picked up - I think - while running svn with ssh.  Any 
> suggestions?

A recent message on this list suggests you should set PATH in .bashrc not 
.bash_profile so that it gets picked up when connecting via ssh.

Can I have one project link to two subversion server?

[yixiaodafang]

Hi,

I want to know whether I can have one project link to two different
server. Here is what I want to do. First I check out the project from
official server. During the time, I will make a lot of intermediate
changes before I finanlly commit them into the official server. Since
not all the changes will be in the final release and a lot of testing
code that should not be checked into the official server. I created
another repository in another computer. I checked all code I got from
official server to the new computer. During the work, I will check the
changes to the second computer for testing and development. After
everything works and cleanup the code, then I will check the code to
the official server. I want to know how can I switch between the two
servers during the development.

Thanks

Frank

RE: Can I have one project link to two subversion server?

[Bob Archer]

> I want to know whether I can have one project link to two different
> server. Here is what I want to do. First I check out the project from
> official server. During the time, I will make a lot of intermediate
> changes before I finanlly commit them into the official server. Since
> not all the changes will be in the final release and a lot of testing
> code that should not be checked into the official server. I created
> another repository in another computer. I checked all code I got from
> official server to the new computer. During the work, I will check the
> changes to the second computer for testing and development. After
> everything works and cleanup the code, then I will check the code to
> the official server. I want to know how can I switch between the two
> servers during the development.

Nope... not really. You have a few options..

1. Use a feature branch on the official server. When your done with your work 
merge it to the main folder path.

2. Create a diff of your changes, apply it to a WC checkout from the official 
server and commit it.

3. Use a distributed 3rd part version of svn. I think there is one called 
silkSVN.

4. You can use Git locally. It will allow you to create local branches, do 
local commits, etc. Then when you are ready you can push whatever you want to 
svn using the git-svn commant.

5. Move 100% to a distirbuted source control like Git or Mercurrial.

BOb

Re: Can I have one project link to two subversion server?

[Ryan Schmidt]

On Apr 23, 2010, at 17:14, yixiaodafang wrote:

> I want to know whether I can have one project link to two different
> server. Here is what I want to do. First I check out the project from
> official server. During the time, I will make a lot of intermediate
> changes before I finanlly commit them into the official server. Since
> not all the changes will be in the final release and a lot of testing
> code that should not be checked into the official server. I created
> another repository in another computer. I checked all code I got from
> official server to the new computer. During the work, I will check the
> changes to the second computer for testing and development. After
> everything works and cleanup the code, then I will check the code to
> the official server. I want to know how can I switch between the two
> servers during the development.

No, that's not how Subversion works.

You could look into svk, which is based on Subversion, works with existing 
Subversion repositories, and I believe does let you work that way.

But the usual way to do what you're asking would be to create a branch on the 
official server and do your intermediate work on that branch, then merge it to 
the trunk when you're done.

Re: Can I have one project link to two subversion server?

[Ryan Schmidt]

Please use Reply All so your replies go to the list too, not just to me.

On Apr 23, 2010, at 17:27, frank wang wrote:

> Thank you very much for the very quick response.
> 
> It seems that I could not do it on svn. Currently I use SVN from
> official server and perforce on my computer, so I can keep track all
> my debug stuff in perforce. After the code works, I clean up the code
> and then check them into the SVN server.
> 
> I do not have the control on the official server and it does allow us
> to create branch for it.

You mean you don't have permission to create a branch on the official server? 
If that's so, and you cannot get permission to do so, then either continue what 
you're doing with Perforce, or use svk as I suggested or git as Bob suggested 
to manage your changes locally.

Re: Can I have one project link to two subversion server?

[David Weintraub]

On Fri, Apr 23, 2010 at 6:14 PM, yixiaodafang  wrote:
> I want to know whether I can have one project link to two different
> server. Here is what I want to do. First I check out the project from
> official server. During the time, I will make a lot of intermediate
> changes before I finanlly commit them into the official server.

You actually asked something that is being debated heavily in the CM
community: Central vs. Distributed repositories.

In Git, you can do exactly what you want, and this is one of the
reasons people like Git. In Git, you can checkout the entire
repository, then use it as if it's your own private repository. Then,
you check in the changes you've made back to the main repository.

A lot of people think this is a better way to do version control, but
one of the problems is that it allows you to work too independently
from everyone else. For example, there's no reason not to check your
changes back into the main repository after working on your project
for a month.

Being forced to use a centralized repository forces you to work with
your fellow developers. You have to take "smaller bites" when you make
changes. You have to do a bit more planning of what you want and think
it through better. You have to coordinate your work with everyone
else. The result is better software.

There are times when distributed version control systems work the
best. Usually, these are the cases where the owner of the repository
really doesn't want to centrally maintain a list of who can or cannot
make changes. Instead, they want to trust a small group and have this
group take the responsibility of tracking others.

However, if you have deadlines and commitments to customers, you are
better off using a centralized version control system. You can track
who can and cannot make changes. You track who made the changes, and
you force people to work together.

You didn't mention why you want to work the way you do. If this is for
commercial software, and you are doing some major work which would
prevent you from checking in your changes on a daily basis, you
probably want to create a feature branch in the main repository. Then,
you want to regularly merge the changes taking place on the trunk with
your stuff, so you don't fall out of sync with the rest of the
project.

If you want to use the distributed method, you can try SVK:
http://svk.bestpractical.com. SVK is a layer on top of the Subversion
repository and allows you to work with Subversion as a distributed
repository.

If you don't have to use Subversion, you might want to look at Git or
Bitkeeper which are built from the ground up to be distributed version
control systems.

-- 
David Weintraub
qazw...@gmail.com

RE: Can I have one project link to two subversion server?

[Curley, John]

Hi all,

Sounds to me like the developers want to avoid branching and merging.
Try it. You might like it.

Seriously though, if you have concerns with branching and merging, I
suggest some training and make some trial runs in a test repository. I
believe there are software tools that will help you manage the branching
and merging.

HTH,
John

Re: Can I have one project link to two subversion server?

[Les Mikesell]

On 4/23/2010 6:02 PM, David Weintraub wrote:


If you want to use the distributed method, you can try SVK:
http://svk.bestpractical.com. SVK is a layer on top of the Subversion
repository and allows you to work with Subversion as a distributed
repository.

If you don't have to use Subversion, you might want to look at Git or
Bitkeeper which are built from the ground up to be distributed version
control systems.


There's also git-svn which appears to work like SVK except that you'd 
use git tools locally on a git branch until you want to push your 
changes back.  Sounds like a reasonable match for this scenario.


--
  Les Mikesell
   lesmike...@gmail.com

commit hangs

[Franz Gregor]

hi there,

when i try to commit my changes to the repository the commitment simply
hangs like this:

f...@fg-desktop:~/workspace/am0$ svn ci -F svn-commit.tmp 
Lösche trunk/models
Hinzufügen trunk/uml
Hinzufügen trunk/uml/Display.uml
Hinzufügen trunk/uml/Display.umlclass
Hinzufügen trunk/uml/use_cases.uml
Hinzufügen trunk/uml/use_cases.umlusc
Übertrage Daten ..

i have to kill the process to gain control of the terminal again.

as far as i worked out this only happens on xml files (openoffice fods
format, eclipse uml diagrams, planner (gnome) files).

here is a strace trace

[pid 19188] read(3, "", 4096)   = 0
[pid 19188] write(6, "", 0) = 0
[pid 19188] poll([{fd=5, events=POLLIN}], 1, 0) = 0 (Timeout)
[pid 19188] close(6)= 0
[pid 19188] close(3)= 0
[pid 19188] poll([{fd=5, events=POLLIN}], 1, 0) = 0 (Timeout)
[pid 19188] write(4, "( open-root ( ( ) 2:d0 ) ) ( del"..., 3533) = 3533
[pid 19188] read(5,  
[pid 19189] <... select resumed> )  = 1 (in [4])
[pid 19189] read(4, "( open-root ( ( ) 2:d0 ) ) ( del"..., 16384) = 3533
[pid 19189] select(7, [3 4], [3], NULL, NULL) = 1 (out [3])
[pid 19189] write(3, "\3414x\325\261m)\226\342\264\334j\263\264\351\227
\n\252\2011\357\250\326~Dz\357+\371J\230\300"..., 3568) = 3568
[pid 19189] select(7, [3 4], [], NULL, NULL 

i'm using svn+ssh pid 19189 seems to be the ssh process and pid 19188 is
subversion.
the server is running SunOS 5.
svn versaions are
client: svnserve, Version 1.6.5 (r38866)
server: svnserve, Version 1.6.2 (r37639)

i can reproduce this failure with another client too.
on the other hand i'm using other rep. without this problem. it is only
on this particular server.
other users of this rep. don't encounter this problem either.

thanks in advance,
franz

Re: Working copy wrong after "svn up"

[Matthias Hryniszak]

Done

http://subversion.tigris.org/issues/show_bug.cgi?id=3621


Best regards,
Matthias.

2010/4/23 Stefan Sperling 

> On Fri, Apr 23, 2010 at 08:38:01PM +0200, Matthias Hryniszak wrote:
> > Thanks for the response - that's really great to hear and I guess I'll
> skip
> > this one in that case.
>
> On second thought, you can still file an issue, with the intention
> that this particular use case will be tested and verified to work
> before 1.7 release.
>
> To facilitate this, can you provide a reproduction script (UNIX shell
> or Windows cmd, whichever you prefer) which starts by creating an
> empty repository and runs svn and other commands until the problem
> is triggered? That would help greatly.
> We could use this script to reproduce the problem with 1.6,
> and later verify that the problem is gone in 1.7.
> We could even add a regression test to our test suite based on
> your script. (A script is great for this because it is a lot
> easier to convert into a regression test than English prose.)
>
> Thanks,
> Stefan
>