Building a tool to make the process automated
lois.desplat at gmail.com
Wed Jun 13 01:34:19 CEST 2007
Cool, was your project one of the ones mentioned on
Yes, it was! http://lwn.net/Articles/236142/
If you are going to version things like /etc, make
> sure that you use a tool that does permissions
> versioning. For much of the files in that dir the
> permissions are as important as their content!
I will pay very close attention to this and it was mentioned in both
It is good to not only be able to ingore files (such
> as with svnignore), but to have files that aren't
> ignored but are not checked in automatically! In
> other words design your tool so that some
> subdirectories/files are versioned but not
> automatically checked in, this is particularly
> important with externals.
> Take externals into consideration since someone might
> be building up a directory view pointing to multiple
Thanks for that comment and even more information on the wiki about it
That sounds nice! You might also want to consider
> using checksums to identify like files like git does.
> Also look at the vserver project's vhashify tool for
> ideas about finding matching files.
Thank you for the idea. Since, I do not know what kind of performance impact
it will have, it is nice to know of other methods that have different
> I do not know how to handle deletion though. When
> > you delete a file, is it possible to delete all its
> > version information too. I know it is very hard
> > to not possible to do in Bazaar, how about in SVN?
> Again, svnadmin will allow you to do this, but as Eric
> mentioned, I would certainly not want this to be
> automatic, after all it seems like that would mostly
> defeat the purpose of this tool.
I agree with both of you that it should not do that automatically. Ken has a
good reason why you might want to do it which is why I asked. It seems
conceptually reasonable that you might want to erase all traces of a file.
Of course, if it came to be that extreme, might as well completely erase all
the hard drives.
The solutions I can think of involve copying the
> unversioned (or changed but not checked in files) to a
> hidden subdirectory which can then be autoversioned
> into a separate junk repository. I don't care if the
> junk repository fills up, the goal is to prune it
> often. If later a file that was unversioned in the
> primary repository gets added to the primary repo, it
> will get deleted from the junk repo, (potentially this
> would be a good time to actually prune it from the
> junk repo?) When I get more time to think about this
> idea I will add a proposal to the wiki.
This currently is way above my head but it is one big problem that I do have
to solve as well. I am sure I'll have more insight once I take cares of all
these other questions going around in my mind.
To you too!
More information about the vcs-home