Hi Juho, On Thursday 16 October 2008, Juho Vähä-Herttua wrote: > Laurent Pinchart wrote: > > To be honest, learning yet another version control system is one of the > > reasons why I'm reluctant to switch over to Mercurial. I would have > > preferred using a git repository instead. > > In fact I would prefer git as well, but if hosting is mercurial only > then... :)
It would be much easier for me to maintain the driver in a kernel git tree, but then we would loose all backward compatibility. Let's not go that far yet :-) > > However, I expect most people to be interested in the latest version > > only. In that case they can easily download a tarball. I might be wrong, > > but I imagine that most people who will download the uvcvideo sources > > directly from the repository will, now that the driver has been included > > in the kernel, just want to try the latest version to get a patch specific > > to their issue. > > Hmm, that's probably the case. > > > How many developers checkout a non-head SVN revision or use SVN log or > > diff commands on the Linux UVC SVN repository ? I'd really like to have > > statistics on such usage. > > I wasn't really referring to the log or even diff commands per se. > Rather keeping oneself up to date with the latest repository without > redownloading it. Good point. It's definitely easier to svn up than to download a new tarball and look at the diff output. > > Very good point. > > http://www.selenic.com/mercurial/wiki/index.cgi/MajorFeatures > > states that Mercurial uses "Bandwidth and CPU efficient HTTP and SSH sync > > protocols" so I guess this won't be an issue. > > Yeah, according to that it seems to be a non-issue. > > > Hence my question above about usage of SVN log and diff commands > > (commit is not an issue as I'm currently the only committer). Do you feel > > that tarballs are unpractical for the majority of users who just want to > > try the latest version ? > > I'm not committing, but sometimes syncing and diffing to check if > there's a workaround for the old camera issue my camera had. :p Feel free to report the issue if it's still present in the latest version :-) > > You only need a single tarball, the one containing the tree you want to > > checkout (in our case this would be the linux-uvc tree). People > > complained in the past about the lack of tarball and the required use of > > SVN so I thought everybody would be happy with tarballs, but it seems this > > is not the case :-) > > But I understood you also need to get the v4l/dvb core sources and > maybe some other modules to compile it, would they be in the same > tarball or how are they got? They would be in the same tree, thus in the same tarball. make && make install (or a small variation thereof) should install everything in /lib/modules/`uname -r`. > Don't take my opinion as the general opinion though, I'm just personally > happier with svn compared to tarballs but most people probably aren't. :) > > > I'd stick to SVN too if it wasn't for the #ifdef's :-/ > > I guess that's good enough reason, as I said if that's the thing to > avoid ugly code then should just go for it. > > > download a tarball. This in itself lowers the barrier. They will also > > have to compile and install the v4l core modules in addition to the > > uvcvideo module. > > > That could raise the barrier, but don't forget that there should be more > > community support as compiling and installing a linuxtv.org tree is an > > operation performed by more users than compiling and installing the > > uvcvideo driver. In a quick chat on the #v4l IRC channel I got told v4l > > developers do > > It's just that the first time I checked out and compiled uvcvideo I > was slightly amazed at how easy and painless everything went. That > sounds like it will go from amazing to a slight pain in the ass in the > future, but that should be acceptable. The v4l tree compilation and installation procedure seems quite straightforward. You can either build and install all modules (make && make install) or configure the ones you need (make menuconfig). It shouldn't get more difficult than that. > I'm mainly replying because you asked for comments, in the end it's your > call since you do the commits. :) And I'm glad you replied, otherwise the amount of comments would have been divided by two. Cheers, Laurent Pinchart _______________________________________________ Linux-uvc-devel mailing list [email protected] https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
