Re: [RFC] Zit: the git-based single file content tracker

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Oct 24, 2008 at 12:31 PM, Jakub Narebski <jnareb@xxxxxxxxx> wrote:
> "Giuseppe Bilotta" <giuseppe.bilotta@xxxxxxxxx> writes:
>> On Fri, Oct 24, 2008 at 1:23 AM, Jean-Luc Herren <jlh@xxxxxx> wrote:
>
>> > If you decide against a shared repository, maybe you want to
>> > consider to not use ".zit.file/", but ".zit/file/" as the
>> > repository?  This would reduce the clutter to a single directory,
>> > just like with ".git".  And moving files around wouldn't be that
>> > much complicated.
>>
>> Right. I'll give that a shot.
>
> By the way RCS which I use for version control of single files use
> both approaches: it can store 'file,v' alongside 'file' (just like
> your '.zit.file/' or '.file.git/'), but it can also store files on
> per-directory basis in 'RCS/' subdirectory (proposed '.zit/file/' or
> '.zit/file.git/' solution)

Indeed, there's not particular reason why both solutions shouldn't be
available. I'll think about implementing it this way:

$ zit init

will indicate that we want to track many files, and thus it will
create a .zit directory under which RCS files will be available.

$ zit track somefile

will start tracking somefile by setting up .zit/somefile.git if .zit
is available or .somefile.git otherwise.

The only problem then is priority. When looking for a file's repo, do
we look at .file.git first, or .zit/file.git? How does RCS behave in
this case?

> By the way, it would be nice to have VC interface for Emacs for Zit...

I'm afraid someone else will have to take care of that, since Emacs is
not really something I use.

-- 
Giuseppe "Oblomov" Bilotta
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux