cvs vs svn reloaded

[Paweł Sakowski]

On Wed, 2005-09-14 at 15:02 +0200, Paweł Sikora wrote:
> Dnia środa, 14 września 2005 12:59, Jakub Bogusz napisał:
> > Well, what I _need_ is to have local SPECS directory regularly updated
> > and be able to easily commit individual specs without traversing
> > directory structure all the time.
> > I _won't_ sacrifice few times more time for multiple chdir()s or typing
> > longer paths during specs cleanups/fixes/cosmetics, just in order to use
> > "more modern" VCS.
> 
> http://subversion.tigris.org/faq.html#symlinks  ?

The problem is that they are, strictly speaking, filesystem symlinks. To
use them you'd have to have all foo/trunk/foo.spec checked out manually
anyway, which makes it pointless (unversioned `for i in */*.spec;do ln
-s $i;done` is way easier and does pretty much the same thing). If you
add a oneliner script with readlink and svn ci, you get qboosh'es
condition of "commits without long paths or chdir" fulfilled. For a
price. `cd SPECS;cvs up` gets more complex (you're working with
thousands of project directories); you can get a script to minimize
typing everytime, but the process will take longer. Plus, you have to
stand the awkwardness of the solution.

I believe an elegant solution would be to have versioned hardlinks. That
is, SPECS/trunk/foo.spec being the same as foo/trunk/foo.spec,
permitting commits to any one of those paths with the same effect. Alas,
subversion doesn't support that. But...

I think it's possible to write a post-commit hook that would effectively
simulate a hardlink capability. The idea is that whenever a modification
of a spec is committed, the change would be applied to the other
location as well (generating another revision). Thus, both versions
would be kept in sync. Preserving the commit log over the merge doesn't
seem to be a problem. There are some special cases to consider regarding
svn {cp,mv,add,rm} of specs. Et voila, you have package directories that
profit from all svn features discussed before, and you keep the
traditional SPECS directory for spec reviews (and grepping the dir
contents for inspiration and/or policy verification).

Does it sound like something that will keep everybody happy?

Note: there might be a race condition on resyncking when there are two
simultaneous commits to both locations. I'd have to check if the hooks
are (or can be) run on a mutexed repository.

-- 
Paweł Sakowski <saq at pld-linux.org>
PLD Linux Distribution