Building a tool to make the process automated

[Lois Desplat]

Hi,

Cool, was your project one of the ones mentioned on
> LWN?


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
articles.

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
> repositories.


 Thanks for that comment and even more information on the wiki about it
http://www.theficks.name/VCS-Home/Organizing

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
advantages/drawbacks.

> 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.

Good luck!


To you too!

Cheers,

Lois Desplat