[prev in list] [next in list] [prev in thread] [next in thread] 

List:       darcs-users
Subject:    Re: [darcs-users] Re: A few comments about Git
From:       "Stephen J. Turnbull" <stephen () xemacs ! org>
Date:       2005-11-22 3:28:19
Message-ID: 87zmnxjr8s.fsf () tleepslib ! sk ! tsukuba ! ac ! jp
[Download RAW message or body]

>>>>> "Juliusz" == Juliusz Chroboczek <Juliusz.Chroboczek@pps.jussieu.fr> writes:

    >> >> I see no reason you can't put a patch in a blob.

    Juliusz> Interesting suggestion.  What does it buy you?

    >> A standard exchange format.

    Juliusz> I'm sorry, Stephen, but I'm afraid you lost me.

    Juliusz> I read this as implying that just dumping native Darcs
    Juliusz> patches into a Git repository somehow makes Git-aware
    Juliusz> tool grok Darcs patches.  Which is probably not what you
    Juliusz> meant.

Yes and no.  It won't grok Darcs patches as patches, but it will
understand abstract structure.

Then a tool that can analyze Git objects can be used to analyze Darcs
patches.  Currently Darcs patches have no internal structure that is
meaningful (except to Darcs and Darcs-aware humans), but that could be
changed.  Eg, suppose that a darcs patch as stored in a Darcs repo was
structured, not as a blob-per-patch as currently, but as Git tree of
patches, with individual hunks being blobs.

We already do this at a slightly higher level in Darcs, with a tag, or
an empty patch recorded with additional dependencies.  But that
structure is intelligible only to Darcs.

    >> (1) you get pristines and/or revision libraries in a format
    >> that is not subject to corruption by typical recursive
    >> operations by developers,

    Juliusz> Recursive tools that descend into _darcs, but somehow
    Juliusz> avoid .git?

Of course `rm -rf workspace will take .git within a few seconds of
obliterating _darcs.  But that's probably what you want, no?  What I
had in mind (note that word "typical") is that .git is highly unlikely
to contain files with names identical to names in the editing
workspace, so something like

for file in `find . -name ChangeLog`; do
  mv $file $file.bak
  echo "$1  Stephen Turnbull  <stephen@xemacs.org>" > $file
  echo "" >> $file
  echo "	* XEmacs $2 is released." >> $file
  echo "" >> $file
  cat $file.bak >> $file
done

does not trash your repo.

I don't claim it's safe.  "Safe" is a directory structure where _darcs
is a sibling of the project tree, not a child of it.  But it's
definitely safer than the current situation.

    >> and (2) you get to leverage UIs and schemas that address Git
    >> content.

    Juliusz> And these UIs will not need to be modified to grok _darcs
    Juliusz> patches?

Of course.  "Leverage" doesn't mean you get it for free, it means that
the same investment has a bigger payoff.

-- 
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.

_______________________________________________
darcs-users mailing list
darcs-users@darcs.net
http://www.abridgegame.org/mailman/listinfo/darcs-users
[prev in list] [next in list] [prev in thread] [next in thread]