[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Switch error / sharing a library strategy

From: Sylvain Vieujot <sv_at_freelance.com>
Date: 2004-03-23 14:28:36 CET

I also have a question on repository layout and sharing strategy.

We have a library that we want to share between several projects.
We used switch to have selected library directories in the projects.
It works fine for sharing the library code among my working copies of
the different projects, but I have 2 problems :

1) The switch works only for the working copies. I mean that if I do a
switch on a subdirectory, I have no way to have my co-workers doing it
automatically.
This is ok (even though I would prefer to have a way to go around that),
but the problem is that when I make a copy of the project's trunk, it
doesn't copy the current library files, but the files before the switch.
You can see that and the errors that it leads to in the following
session.

2) The following session makes an error (I'm using svn 1.0.1 / Mar 18
2004)

$ cd ~
$ mkdir tst1
$ cd tst1
$ svn co file:///data/My/Progs/Java/subversion/test/
A test/lib
A test/lib/trunk
A test/lib/trunk/libweb
A test/lib/trunk/libweb/test.jsp
A test/project1
A test/project1/trunk
A test/project1/trunk/libweb
A test/project1/trunk/libweb/test.jsp
A test/project1/branches
A test/project2
A test/project2/trunk
Checked out revision 28.
$ cat test/lib/trunk/libweb/test.jsp
libv1
$ cat test/project1/trunk/libweb/test.jsp
project1

$ cd test/project1/trunk/libweb/
$ svn switch file:///data/My/Progs/Java/subversion/test/lib/trunk/libweb
U test.jsp
Updated to revision 28.
$ cat test.jsp
libv1
$ echo libv2>test.jsp
$ svn ci -m "update test.jsp in project1"
Sending test.jsp
Transmitting file data .
Committed revision 29.
$ cd ../../..
$ svn update

U lib/trunk/libweb/test.jsp
Updated to revision 29.
# This is Ok, the file is updated in the library
$ svn copy project1/trunk/ project1/branches/v1WithSwitch
A project1/branches/v1WithSwitch
$ svn ci -m "branch project1"
Adding project1/branches/v1WithSwitch

Committed revision 30.
$ cat project1/branches/v1WithSwitch/libweb/test.jsp
libv2
#This is Ok
#Now test on another working copy :
$ cd ~
$ mkdir tst2
$ cd tst2
$ svn co file:///data/My/Progs/Java/subversion/test/
A test/lib
A test/lib/trunk
A test/lib/trunk/libweb
A test/lib/trunk/libweb/test.jsp
A test/project1
A test/project1/trunk
A test/project1/trunk/libweb
A test/project1/trunk/libweb/test.jsp
A test/project1/branches
A test/project1/branches/v1WithSwitch
A test/project1/branches/v1WithSwitch/libweb
A test/project1/branches/v1WithSwitch/libweb/test.jsp
A test/project2
A test/project2/trunk
Checked out revision 30.
$ cat test/project1/branches/v1WithSwitch/libweb/test.jsp
project1
# !! BAD !!! Doesn't match the libv2 committed on revision 30 in the
previous working copy
#Now, let's test the first working copy :
$ cd ~/test1/test/project1/branches/v1WithSwitch/libweb/
$ cat test.jsp
libv2
$ svn update
svn: Checksum mismatch for '.svn/text-base/test.jsp.svn-base'; expected:
'ac27feb13671c9d6519e97dc0b6981fc', actual:
'c8581256575dd1a01a0761811dd0a119'
# WORSE : svn Error

# Let's make another example
$ cat test/project1
$ svn copy trunk branches/v2
A branches/v2
$ svn commit -m "test 2"
Adding branches/b3

Committed revision 31.
$ echo updateInV2>branches/v2/libweb/test.jsp
$ svn commit -m "Error while updating branch v2"
Sending project1/branches/v2/libweb/test.jsp
Transmitting file data .svn: Commit failed (details follow):
svn: Base checksum mismatch on '/project1/branches/v2/libweb/test.jsp':
   expected: c8581256575dd1a01a0761811dd0a119
     actual: ac27feb13671c9d6519e97dc0b6981fc

Is there a better strategy to share a library code within several
projects ?
The only solution we've found so far are to not share the code, and to
resynchronize permanently with merges, but this is very un-convenient.

Thank you,

Sylvain Vieujot.
Received on Tue Mar 23 14:29:17 2004

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.