[sane-devel] The future of the SANE-Standard

[kilgota at banach.math.auburn.edu]

On Mon, 24 Dec 2007, Alessandro Zummo wrote:

> On Mon, 24 Dec 2007 15:36:09 +0100
> Julien BLACHE <jb at jblache.org> wrote:
>
>> "m. allan noah" <kitno455 at gmail.com> wrote:
>>
>>> can we have both svn and cvs enabled at the same time? if not, we
>>> would have to migrate...
>>
>> I think we can, but migrating is the best solution as it'll avoid
>> confusion :)
>
> svn would surely be useful for sane 1.1/2.0 . we can keep
> 1.0 o cvs and migrate it at a later stage if required.
>
> I know there's a way to convert a cvs repository to svn
> without loosing information.
>
>
> -- 
>
> Best regards,
>
> Alessandro Zummo,
>  Tower Technologies - Torino, Italy
>
>  http://www.towertech.it

Hi,

Still subscribed to your list after all these years, since the time that 
the Canon N640U came out. As you are debating about SVN, I thought I might 
share some of my experiences working on a similar project.

The Gphoto project has converted over to SVN some time ago. It is a bit 
different from CVS for the user, but it works OK, I think. I was not one 
of those who was involved in doing the change and thus cannot report about 
that, but it seems to have gone fairly smoothly.

The differences from the developer-user's point of view:

1. The update command will synchronize you with the main repository. I 
always do that before putting anything new into my own local tree. That 
is a final double-check to make sure that nobody has made some global 
change which affects my code in a particular camera support library 
without my knowing of it.

2. The command for seeing what is happening after one has added some new 
changes is "svn status".

3. After doing that and all is good, one does "svn commit" and the changes 
go upwards, pretty much instantly (different from CVS in that respect, but 
it may just be better bandwidth and servers at Sourceforge).

4. It is nice that, once your local tree is set up with commit privileges, 
you do not need to use the password every time you commit.

5. The commit will automatically synchronize your whole tree with what is 
on the other end. That is one reason why it is good to be sure that 
everything is in order before you do it. You also do not need to do the 
commit from within the particular subdirectory where you were working. For 
example, if I do some changes in libgphoto2/camlibs/sonix and at the same 
time some changes in libgphoto2/camlibs/mars, then one commit will send 
both sets of changes up.

6. One can have work files and first draft files lying around inside the 
local SVN tree, and they do not get sent up on commit, unless they have 
been explicitly included in the set of files controlled and recognized by 
SVN. But an update to a file already recognized does not require one to 
make that file to be re-recognized. Me, I do not make a practice of using 
this feature because I feel it might lead me into temptation. Thus, my own 
practice is to keep a pristine SVN-controlled tree and another, distinct 
working copy at all times.

7. The one thing I do not like after we did the switch is that in 
libgphoto2/camlibs we went over to a one-Makefile system and each 
subdirectory of camlibs has in it only a Makefile-files and one can no 
longer work on one subdirectory and re-compile and re-install from within 
it. Rather, one must go back up one step and re-compile and re-install 
the entire libgphoto2/camlibs directory. The re-compilation is not so bad, 
of course, if one has done changes only in one subdirectory. But then the 
whole set of camera drivers has to be re-installed. This is slow and, 
frankly, is a pain in the ass. I don't think that SVN all by itself would 
require you to do things this way, and if not then my advice is don't. If 
it does require that, then it is a drawback of SVN. If there is a way 
around this, then excuse my ignorance. In that case it is just something I 
never figured out how to work around.

My two cents. I hope this helps you to come to a decision.

Merry Christmas,

Theodore Kilgore