On 20/09/2012 16:25, Iavor Diatchki wrote:
perhaps we should have a well-defined place in the repo where we keep
the finger-prints associated with tags and branches in the main repo?
This would make it a lot easier to get to a fully defined
previous/different state.
We do have tags for releases, so you can say
./sync-all checkout ghc-7.6.1-release
and get the exact 7.6.1 sources.
I wouldn't object to also having fingerprints in the repo too though.
Cheers,
Simon
On this note, could someone send the link to the 7.6 fingerprint? Ian
said that it is somewhere in the nightly build logs but I don't where to
look.
-Iavor
On Thu, Sep 20, 2012 at 7:20 AM, Simon Marlow <marlo...@gmail.com
<mailto:marlo...@gmail.com>> wrote:
On 19/09/2012 02:15, Iavor Diatchki wrote:
> exactly what git's submodule machinery does, so it seems
pointless to
> implement the functionality which is already there with
a standard
> interface. Thoughts?
http://hackage.haskell.org/__trac/ghc/wiki/DarcsConversion#__Theperspectiveonsubmodules
<http://hackage.haskell.org/trac/ghc/wiki/DarcsConversion#Theperspectiveonsubmodules>
I have seen this. Our custom "fingerprint" solution has the
exact same
drawbacks (because it does the exact same thing as sub-modules),
and in
addition it has the drawback of
1. being a custom non-standard solution,
2. it is not obvious where to find the "fingerprint"
associated with
a particular branch (which is what lead to my question in the
first place).
Well, it doesn't quite have the same drawbacks as submodules,
because our solution places a burden only on someone who wants to
recover a particular repository state, rather than on everyone doing
development.
I think it's worth keeping an eye on submodules in case they fix the
gotchas in the UI, but at the moment it looks like we'd have a lot
of confused developers, lost work and accidental breakages due to
people not understanding how submodules work or forgetting to jump
through the correct hoops.
I'm not saying fingerprints are a good solution, obviously they only
solve a part of the problem, but the current tooling for submodules
leaves a lot to be desired.
Cheers,
Simon
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
